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Abstract 


This thesis is concerned with the problem of controlling concurrent access to shared 
data. A language construct is proposed to enforce such control; a specification language 
is defined to describe the formal requirements of such control; and verification 
techniques are given to prove that instances of the construct satisfy their specifications. 
The techniques are justified in terms of the definition of the construct and the 
definition of the specification language. Results are given for a program that 
implements a number of the techniques, illustrated by verifying several versions of the 
readers-writers problem. Interactions between instances of the construct are discussed 
in the context of a simple file system. 
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1. Introduction 


This thesis is concerned with the problem of controlling concurrent access to - 
shared resources, In systems where several processes may“attempt to concurrently 
access the same resource, there is a need to impose some order on those accesses. If 
certain orders are not enforced, certain classes of access td the résotirce may conflict and“ 
cause erroneous results, Other classes of accéss to’ the ‘same’ resource’ tay proceed 
concurrently without conflict. This is true whether the resource is a data base, a printer 
spooler, a file system, or a communications network, although the definition of the 


classes of access may be specific to the resource. 


Given this framework, we can informally define a few terms.’ Two-accesses are 
concurrent. if both: accesses have’ started, yet neither has completed... Typically... 
concurrent access is controlled through exclusion, where a process executing one:class. - 
of access prevents the initiation of another access from:any. of.a-set-of classes: When - 
one access excludes another, the latter must ‘wait-for the former:to complete. . Lf .one- 
access 1S walling for another, which j is waiting for the ist to one then no progress 
can be. made on either, which | is called deadlock. If two processes are ready to initiate 
accesses, yet one access excludes the other, then the process'that proceeds is said to have 
priority over the other, A. process. that is ready. ta. proceed, yet. is continually denied 


progress, suffers from starvation. 


We wish to ensure that programs executing: concurrently: on shared resources 
obtain correct results, where correctness is defined in terms of programs mecting their 


specifications. We wish to show, for properly designed programs, that certain accesses 
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exclude others, that the proper accesses are granted priority, that appropriate access 
may proceed concurrently, that there is no deadlock, and that there is no starvation. We 
limit this concern to the issues that are specific to concurrency, and not those that apply 
to determining whether the access, executed by itself, has the correct effect on the 
resource or returns the .correct information. Also, we are not concerned with 
concurrency issues unrelated to accessing resources, such as process creation and 


deletion. 


1.1 Initial decisions 


Our. first decision. is that it is desirable to -have a. separate programming 
language construct to realize reliable control. of concurrent access. We believe it 
insufficient to simply propose a construct and. present: some examples of its use. A 
language designer should also provide tools that increase the utility and reliability of a _ 


language construct. Consequently, this thesis presents: 
* A language construct to control concurrent accesses to shared resources. 


* A definition of the semantics of the construct. 


*A specification language to describe properties of concurrency control 
that are to be realized through this construct. 


*A verification methodology that is used to prove that instances of the 
construct satisfy their specifications. Ba coess 


* The design of a program to make use of this. methodology. and perform 
verification. 


One of the contributions of this thesis is that all of these elements are presented 


together for a single construct. 


Our approact to concurrency‘ control is: heavily influenced by by the monitor. 
construct of {Brinch Hansen 72] and [Hoare 74], and the programming languages CLU 
{Liskov et. al. 77, Liskov 79a] and Alphard [Wulf 78}, whieh-in turn awe much to Simula 
[Dahl 72}: In these languages, access to: data objects is achieved through:a dimited set-of. 
operations, which are generally implemented-as:- procedures. Just as:CLU:and Adphasd 
separate implementation details from the abstract appearance of data objeets,. our 
objective is to separate concurrency control from access to data objects. The monitor 
construct has a similar goal, although a slightly different view of data. The connechon . 
between concurrency conttst and data abstraction is a key issue in defining our 


construct and in our verification techniques. 


Verification does not prove that programs operate correctly, in the sense that a 
verified program performs exactly as desired. There.is.often no reason to believe that. 
the specifications. are better than the programm text, for describing, the desired behavior 
for the program. Verification performs. the task of taking two different descriptions of a 
problem solution and showing thatthe. descriptions. agree,:.in_ the sense that every 
behavior that the program exhibits is allowed by the specifications. The two 
descriptions are quite different in kind: the code is an algorithmic description, and the 


specifications describe the effects of exceuting the code, ‘The confirmation of arriving at 
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the same answer through two different methods ought to increase:confidence in the 


solution. 


. 


We wish our techniques to be valid whether there is true concurrency, using 
multiple processors, or simulated concurrency, using a fitilaplesed single processor, or 
a mixture of the two. To accomodate this range of behavior, we have described accesses 
as being concurrent if both accesses start before either ends. This definition may.seem 
_overly broad, since two accesses are considered to be concurrent if one access occurs as 
part. of the other. We choose to make a conservative decision: two accesses are 
potentially concurrent if the start of either access can occur. between the start and finish 


of the other. 


1.2 Modularity 


Large programs are usually difficult to understand and modify not because of 
their size, but because of their complexity. This complexity is far more often due to 
interactions between parts of programs than it is to inherent complexity in the task 
being performed. The notion of modularity is widely accepted as a means of limiting 
these interactions, although the term is defined in various: ways. ‘This principle is useful 
in constructing programs, in modifying programs, and in verifying -programs.. 


Modularity in verification has also been called the independence principle: 


The proof of a routine may only depend upon its own specifications and 
implementation, and upon the external specifications of the routines to’ 
which it textually refers. (Good, Cohen and Keeton- Williams 79, p.45] 
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We propose to make use of the following kinds of modularity: 


* Data abstraction is the organization of data.into distinct objects, where 
each object belongs to a distinct data type, and direct access to the objects 
of any type is limited to the operations of the type. This definition of data 
abstraction follows the lead of the CLU programming language. 


* Concurrency control is separated from data access. The implementation 
of concurrency control is kept distinct from the implementation-ef. data: . 
access, although the external interface of the two implementations may be 
similar. 


* Specifications of concurrency control are separated from. speciftcations.of 
other properties of a program. Further, these Speci ications are meant to 
~-be independent of any implemeritation: : : 3 


* Verification of concurrency control is separated from other program 
verification. techniques. In. particular, :the..verification .of access. to a 
resource and the verification of the concurrency control for such access 
are independent, although each-may assume the Speéifications: of the - 
other (we will assume an absence of circularity, since it is a separable 
issue). 


It is possible to find fault with modularity, since the kinds of separation we 


have described may make it more difficult to acheive other desirable properties, 


* The principle of modularity can be misapplied: the wrong kind. of 
separation prevents necessary data from being Coimmunicated from one 
place to another. We hope to show through the-use of examples that the 


kinds of modularity we propose to use do not Loon necessary 
information from being in the appropriate places, - 
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* Modularity can be inefficient: the mechanism for transferring from one 
context to another, as in a procedure call or process switch, can be 
expensive. Further, by limiting access to certain data, certain 
computations may be redundant. We will not address this issue directly 
in this thesis, but will return to this objection in our conclusions. 


L3 Related work 


Much of the initial work on the construct we propose was done in conjunction 
with Carl Hewitt [Hewitt and Atkinson 79]. Since then, there has been a divergence in 
our efforts; this thesis explores issues of automatic. verification of concurrency control, 
while Hewitt has concentrated on more primitive control of concurrency in a context 
where programs communicate by passing nesses Some of this work can be found in 


[Hewitt, Attardi, and Lieberman 79]. 


Below we briefly discuss related work on language constructs, concurrency 


specifications, semantic models, and some differences in our approach from other work. 


1.3.1 Related language constructs 


Most authors in this area note the importance of limiting the interactions 
between concurrent processes through the use of language constructs specifically 
designed for this purpose. We have a similar approach in this thesis, with the addition 


that we attempt to relate concurrency control to abstract (user-defined) data types. 


We have already noted the intellectual debt owed to the monitors of Brinch 
Hansen and. Hoare. For now, we characterize the monitor approach by noting that 
concurrency is controlled by only allowing one process at a time to execute an operation 
that belongs to a monitor, Given that initial exclusion: further execution orders may be 
imposed by the monitor operations, We will present a more detailed comparison of our 


constr uct with monitors in Chapter i 


Another'line of thought in concurrency control is to fimit parallel processes to 
communicating through the passing of messages: Various atithors have proposed such 
an approach, among them [Good, Cohen and ‘Keeton: Williams 79, Hoare 78, 
Feldman 79]. Concurrent actions only proceed when a process tha is sent a message 
chooses to receive it. Exclusion for a class of access derives from a refusal to accept a 
message of thet class. This approach is particularly well suited to distributed systems, 


where different processes may reside on widely separated processors. 


These two approaches are not as different as they might initially appear. 
Although our presentation will follow the first approach, we will argue in this thesis that 


our techniques are valid for the second approach as well. 
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1.3.2 Concurrency specifications 


Our work on specifications is strongly influenced by Greif [Greif 75). In this 
approach, certain events related to an ee are identified: access request, access start, 
and access finish. Specifications are given by indichtina whieh orders of these events 
are required. For example, suppose that the scecution of one kind of access (call it X) 
prevents another kind of access (call it Y) from ‘starting: We can specify this 
requirement by stating that no Y. access start event can ogcur. between any: X access start 
event and the corresponding X access finish event. 


A similar approach to specifications appears in [Laventhal 78), in which _ 
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specifications are used to synthesize i im plementations to realize = concurrency control. 


1.3.3 Related semantic models 


Various models have been used to describe concurrent execution of programs. 


In the models we discuss here, a program proceeds from state lo state by: atomic actions, 


* In [Howard 76, Good, Cohen and Keeton-Wiltiants 79], and in our work, 
actions that take place are recorded in sequences called /istories, and 
program semantics are described by giving predicates that must be 
satisfied for histories. 


*In [Greif 75], actions are related by partial orders called behaviors. 
Program behavior is given by predicates on these partial orders. 


*In temporal logic (a survey-level explanation of this modef appears in .- 
[Lamport 80]) the model uses sequences of states, rather than actions, 
. Eredicnts that describe program: behavior ‘May be Applied t to nee 


sath: 


commen sequence of states as a prefix, fora branching time ne 


* Another related -modet, based’ on ‘trees’ ‘of states, is presented’ in 
{Owicki 75). Given an initial state and a program, the behavior of the 
program is characterized by a tree of states, where the arcs represent 
execution of an action that leads: to the next state. . 


All of the above models use some. structure to.:relate either states or actions, and 


describe program behavior by giving predicates on:such structures, 


Iti is Possiote to discuss states in terms sof equivalence classes of histories (or 


behaviors). For example: 


\ 


[There] fs a correspondence between states and behavior that allows one ta. 
define the states of a system as. an equivalence relation over the possible 
behaviors. [Greif 75, p. 72] 
We believe it better to think of predicates on histories rather than to attempt to regard 
states as equivalence classes. The distinction lies in our concern: with certain properties 


of objects at any particular time, rather than-the entire state of the object. 
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1.3.4 Differences in our work 


We approach concurrency control not just by defining a language construct, 
but also by providing specification and verification ‘methods for'the construct. Further, 
these methods are actually demonstrated in a simple automatic verifier. By providing a 
wide range of support for a relatively narrow constrict We hope to illustrate the benefits 


of a unified approach to controlling concurrent access io resources. 


We have attempted a greater use of modularity than is commonly found in 
other works. In particular, we couple:controt ‘of concurrent access to the principles of 
data abstraction with strong typing, while maintaining separation of concurrency 


control specification and verification from data access specification and verification. 


1.4 Plan of thesis ~ 


Chapter 2 introduces the serializer language construct, which is a method for 
controlling. concurrent access. An informal presentation is made of the syntax and 
semantics of the construct. An cxample,. based on the readers-writers problem, is. 
discussed in detail. A simplification-of the serializer construct is:defined for use in later 
chapters. A translation of serializers into clusters and semaphores is given as a possible 


implementation strategy. 


Chapter 3 presents a simple semantic model that supports concurrency, and 
uses i to define more precisely the simplified serializer construct. A definition 


language based on first-order predicate calculus ts used to describe serializers as 
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enforcing limitations on the execution order of programs. 


Chapter 4 discusses the four kinds of concurrency control specifications used 
in this thesis. A simple specification language for concurrency control is defined. 
Specifications are given for the readers-writers problem, with several variations, and the 


bounded buffer problem. 


Chapter 5 presents and justifies rules that are used to verify that serializers 
meet their specifications. Although the definition of serializer semantics and the 
definition of the specification language are sufficient to allow us to verify serializers, it 
would be difficult to write an automatic verifier that directly uses these definitions. 
Therefore we define and prove a number of inference rules that allow us to infer. 
specification clauses given the assumption (or proof) of other specification clauses,. An 


example is given of how the rules allow verification in a simple mechanical fashion. 


Chapter 6 describes a program that uses the verification rules to establish that 
a serializer meets its specifications. We first describe how the structure of the program 
incorporates. the verification rules, and then present examples of proofs that the 


program has performed. 


Chapter 7 discusses issues related to interaction of serializers, and presents an 
extended example of serializer usage: a simple hierarchical filing system. Guidelines 
are given for providing scrializers for. data types that are originally uscd in a 


single-process environment. 


Chapter 8 contains a discussion of how the work in the previous chapters can 


be extended to cover more complex problems and more complex serializers. 


Several examples of serializers are presented in the appendices, and are 
referred to from time to time in the body of the thesis. The last appendix presents a 


table showing where the various definitions and rules used in this thesis are defined. 


ao 


2. Serializers 


This chapter introduces the serializer construct, which is intended to provide a 
modular method of concurrent access to: shared: data: objects. Related programming 
language constructs are monitors [Brinch Hansen 72, Hoare 74), pat. expressions 


[Campbell.and Hi abermana 74], and communicating seq juential processes [Hoare 78) 


We treat the serializer construct as an extension to the CLU Programming 
language [Liskov et. al. 77, Liskov 79a]. However, the basic ideas behind serializers go 
beyond any particular programming language, Earlier, versions of the serializer 
construct were presented in [Hewitt and Atkinson'77] atid [Hewitt and Atkinson 79] 


using a significantly different language. 


In this chapter we describe the, rationale. for the design. of the serializer 
construct, informally define the syntax and semantics of serializers, and present an 
‘example of a serializer. “Then we describe the limited version af. serializers that we will 
be using in-the remaining chapters, give a possible implementation of serializers in 


terms of semaphores, and compare the serializer and monitorcenstructs. 
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2.1 Serializer design issues 


We believe that a language construct for controlling concurrent access to 


shared objects should have the following qualities: 


* The shared objects should be ene into identifiable sets of objects, 
each set being a resource. A resource should also: be treated as an object, 
allowing resources to be composed from other resources. Each resource 
can only be directly accessed through a set of operations associated with 
the resource. 


* The construct should separate control of concurrency from the algorithms 
that access the resource. This separation simplifies both the concurrency 
control and the resource -access. Some concusrency .may be lost by 
requiring complete separation, since it is likely to be difficult to partially 
overlap operations, However, we believe that the added-simplicity i is well 
worth the reduced concurrency. 


*To aid reliability and verifiability, the shared resource should not be 
accessed except through an object that controls access.to the resource. 
The concurrency control construct. should enforce this restriction, since 
relying on programmers to follow cotiventions’is:not satisfactory. 


* To case the writing of programs that access resources, operations that 
access the object controlling the resource should.appear to. be,.as nearly as 
practical, the same as the operations that access the resource. That is, the 
construct that controls-concurrency should have the same appearance to 
the user as the construct used for the resource. 
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Based on these criteria, we designed the serializer construct to have the 


following characteristics: 


* Like the cluster construct of CLU, the serializer construct is used to 
define data types by defining a set of operations for. each type. The 
Objects of a data type defined by the serializer construct are called 
serializer objects.. Each serializer object is used to control a separate 
resource object. The operations of the data type are serializer operations. 
For the sake of modularity, serializer objoets can only : -be saccessed 
through the appropriate serializer operations. 


* The execution of protected parts of a serializer operation for a particular 
serializer object precludes the simultaneous execution of protected parts 
of any serializer operation on the same sscriatizer object. The process 

_ executing a protected part of an operation is said to have possession of the 
serializer object. 


5a During the execution of a serializer operation, possession of the serializer 
object can be released ‘and regained. {t’ts particutarly useful to relvase 
possession while accessing the resource, thereby permitting concurrent 
activity involving the serializer object. After the resource’ access, 
possession is regained to indicate that. the aceess,is complete. This 
temporary release of possession permits external procedures to be 
‘invoked: from a. sertalizer ‘operation: white “allawing other serializer 
operations to continue. 


* During the execution of-a serializer operation, it may become necessary to 
suspend execution to wait for some condition to become true. For 
example, ifsome operation needs exclusive access to the fésource, it must 
wait until no other resource accesses are in progress. During this pause, 
possession of the serializer object is released to allow other requests to 
proceed concurrently as far as they are able. . 


Es Be 


Figure 1. A picture of a serializer object 


Serializer object 


I 
| 
| 
| $-----------= + 
| ; | | 
Request --> (Pause) Request'--> | 
| | I. 
| | Resource | 
| | | 
Reply <--- . (Pause) Reply'<--- | | 
| | 
+ 


A graphical description of how the serializer construct is’ used is shown in 
Figure 1. A Request is the start of an operation, and a Reply its éeeinination (possibly 
passing back irformation), The intended effect of the serializer is to imposé.an ordering 
on the requests and replies as they are transmitted: between the resource and the 
requesters. The (Pause) is opHorit based on: whether the respurce access. requested 
can be performed immediately rohie the request enters the. serializer. In most. cases, a 
serializer operation passes. the information it receives” ‘from ihe’ caller: to the 
corresponding: resource operation, and. aise the - ios hiicaia ea it. receives from the 


resource operation to the caller. 


2.2 Serializer syntax and mechanism 


This section gives a brief syntax for the serializer construct and the statements 
used only by serializers. We also give an informal description of what each form is used 


for and how it works, 


The syntax used for a serializer is similar to the syntax used for a CLU cluster. 
The header names the serializer and lists the externally available operations. Then the 
representation type for the serializer is given, which determines the names to be used 
for the components of the serializer object. Then the operations are given as 
procedures. The form of aserializer is: 
name = serializer is operation_name_list 
rep = representalion_ type 
operation_name = proc ( formal. arguments 
optional_return_list 
optional_exception_ fist 
procedure_body 
end opcration_name 
. 4 other operations 
end name 


We have used italics to informally indicate syntactic quantities. 


As with clusters, the serializer construct. defines a new: data:type, where the 
type is denoted by name. Certain of the operations ‘are -used to create: new serializer | 
objects of the named type, while other operations are- used-toe- access the. serializer. 
objects: Operations named. in the eperatiad Nani... list.ave. the, externally. availahle 


iff 


opel ations, and maybe used by code outside of the serializer, Operations not ‘named i in 
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the operation_name_list may only be used internally. Starting the execution of any 
externally available operation that directly uses the serializer object requires that the 
executing process gain possession of the serializer object (starting execution is shown as 
Request in Figure 1). Termination of an operation that has possession releases 
possession (termination is shown as Reply in Figure 1). To reduce the likelihood of 
deadlock, an operation that has possession of a serializer object is prohibited from 


directly calling another operation that requires possession of the same serializer object.! 


We have also added two new kinds of statements that can only be used in a 
serializer. The enqueue statement is used to suspend ‘execution (and release possession) 
until some condition is satisfied (shown as (Pause) in Figure 1). The statement has the 
form: 

enqueue queue_expression until boolean_expression | 
The queue_expression denotes a queué that is, used to impose a_first-in-first-out 
discipline on processes waiting for conditions. The boolean_expression denotes the 
condition that is required to be true before a process can continue execution. Such a 
condition is called a guarantee. When a process is waiting for the condition to be true, 
we say that the process is wailing in the queue, since some igen learn of the process 
“is stored in the queuc, ‘When a process waiting : in a queue is allowed to proceed, it 
regains possession of the serializer object, the process identéfication is removed from the 


queue, and the enqueue statement terminates.. 


1. In practice, ft mity not be possible to detect when this: oceurs. “This does net affect our objective, 
which fs to reduce the chances for errors. We do not believe that it is possible for a language restriction to 
completely climinate this kind of crror-without unduly affecting the expressive power of the language. 
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The queues used in serializers are first-in-first-out unless otherwise specified: 
If some process starts execution of: an enqueue ‘statement before another. process. starts 
execution of an enqueue statement for the same quetie, the first process will complete 
execution of the enqueue statement before the secorid process, provided. that either 


statement terminates. 


The join statement is used to perform some body of statements that should be 
executed while no/ in possession of the serializer object. ‘The:statement has the form: 


“kp 


join crowd_expression 
body_of_statements 
end . 3 ¥ ‘ lita : ph: 2 


A. crowd_expression denotes a set used to identify the. processes that have started 
executing a join statement but not conspleted.it: There may be several such sets, called 
crowds, so that different classes of access can: be distinguished.? Fhe join statement 
starts by placing some identification of the executing process into. the specified crowd 
and releasing possession (shown as Request in Figure 1). After possession is released, 
the body of statements is executed. Finally, possession is regained (shown as Reply *.in 
Figure 1), the process: identification . is’ removed: from. the .ceewd, and. execution 
continues afer the: end of the join statement. : Typically,.a joie inside,of an. operation is 


performed to invoke the corresponding operation of the resource. 


. An example of the use of priority queues appears in Append#e-].- 

‘The join statement is so called because the process executing the statement joins a crimd of similar 
pruceases. ft not be confused. ial fork and join: primitives: used: for progess creation and termination in 
other languages. : = Hoe aye : 
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A process attempting to start or continue exccution of an Speraion on a 
serializer object must wait until there is no other process that has possession of the 
serializer object. If the process is waiting for some condition to be. satisfied, it does so in 
an explicitly named queue of an enqueue statement. If the process is waiting to gain 
possession at the start of an operation or at the end of a join statement, it does so in an 


implicit queue called the external queue, which is serviced in first-in-first-out order.’ 


Possession of the serializer object is released at the start of an enqueue 
statement (after the process is placed on the queue), the start.of a join statement (after 
the process is placed in the crowd), and at the end of an operation. Whenever. 
possession is released, the explicit serializer:queves are examined:to determine whether 
any queue has a. process at its head with a-true guarantee.: If any of the guarantees are 
true, then one of those associated waiting proces-es will get:possession of the serializer, 
and be removed from its queue. Then the process can proceed with the execution of 
the operation. In evaluating the guarantees, there is no assurance that the guarantees 
will be evaluated in any particular order, or-that they.-will all be:evaluated unless ail 
evaluate to false. If at guarantees are false, then the process.on the external queue that 


has waited the longest (if any) is removed from. the-queue:and gaihs possession. 


4. We have chosen to use a single external queue for simplicity ofexplanation. Using a single external 
queuc is a valid implementation, although it is not the only valid inplementation. 
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2.3 An example: the readers-writers problem 


The general readers-writers problem [Courtois, Heymans and Parnas 71] 
presents a simple resource that is to be accessed by concurrent processes. There are two 
operations on the resource, read and write, A process performing a read operation is 
called a reader; while a process performing. a. write operation. is called a writer. In 
keeping with the serializer methodology, we have split the problem into writing a 
cluster to implement the resource and constructing a serializer that encapsulates such a 
resource. The basic constraint on concurrericy is that readers ‘Should not access the 
resource concurrently with writers, and wiitérs. should not access the resource 
concurrently with other writers. The general readers-writers. problem imposes no 


further requirement on the order of processing for operations. - . 


The example we present int Figure’ 2 has the Higuirennent that if a read 
operation on the serializer starts before a write Operation on the serializer, the reader 
will access the resource before that writer, and ‘that this. first:in- “first-out (FIFO) 
ordering is also imposed on writers with respect to readers, and on | writers with respect 


to other writers. This variant of the readers-writers problem i is discussed i in [Greif 75). 


In the FIFO serializer, there are three operations, one to create a new 
serializer object (and new resource), one to-read a value associated with a key in the 
resource, One to write a value associated with a key in the resource. Otrly the serializer 


operations that access the representation (rep) of a serializer object argument need to 
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Figure 2. FIFO serializer 


% The following serializer is a first-in-first-out solution to the 
% readers-writers problem. 


FIFO = serializer is, : 
create, % Create a new serialized fesource object 
read, % Read a value from the resource given a key 
write % Write a value to the resourcé given a key: 
% Each serializer object has the foVlowing ‘representation - 
rep = record [rc: crowd, % readers’ crowd 
we: crowd, . %& writers’ crewd 
xq: queue, ' % common queue 


res: resource] % unserialized resource 


create = proc ¢() returns (cvt) 
return (rep${rc: crowd$create (), 
we: crowd$create (), __ 
xq: queue$ctreate ete : 
res: resource$create () }) 
end create : 


read = proc (x: cvt, k: key) ratuens (value)... 


% Wait until there are no active writers 
enqueue x.xq until crowdSempty, (x,wc) . 


% Become an active header & perform ue tread 


join x.¢rc 
return eherource toes (x. dee k)) 
end: 

end read 


write = proc (x: cvt, k: key, v: value) 


% Wait until there are no active writers or readers 
enqueue x.xq until crowdSempty (x.rc) & crowd$empty (x.wc) 


% Become an active writer & perform the write 
join x.we 

resource$write (x.res, k, v) 

end 
end write 


end FIFO 


gain possession of the serializer object.> The use of vt as a type declaration for 
arguments to operations indicates which arguments are serializer objects viewed as their 
representations. The use of evt follows the CLU usage, in that it represents a type 
conversion between abstract type and representation type that is performed: at the 
interface of an operation. Each serializer operation is limited to one cvt argument, since 
there is no provision for gaining simultaneous Possession of multiple serializer objects. 
There is no restriction on the use of cvt used as a return 1 type (even if om we allow multiple 


serializer objects to be returned). 


In the read operation of the. FIFO. serialinct: : the. -quammniee is 
crowd$empty(x.wc). Therefore, no readers will begin to read from the resuiee until 
there are no writers accessitig the resource. laud im the write operation, the 
guarantee is crowd$empty(x.rc) & crowdSempty(x. wey: whidi prevents a writer from 


procecding until neither readers nor writets are accéssitg the resource. 


The importance of having sole possession of the serializer object can be 
iflustrated by examining Figure 2 and considering the consequences of hot having such 
a restriction. For example, if a writer did not have sole socom: of the serializer 
object aher it performed its enqueue, another weiter could access the resource between 


the first yriter’ s execution of the enqueue statement and thie join statement. This would 


5. The create apcration dees not need to gain possessing, since no, _procgsses other than the process 
exccuting the create operation could access the object, : 

6. Note that -as an argument type description, eve requires a conv ersion from abstract lo representation 
type, and asa return type description, the conversion is from representation tw abstract type. 
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allow simultancous access to the resource by two writers, which violates our initial 


requirements for the serializer. 


2.4 Simple serializers 


It is infeasible to present definition, specification, and verification techniques 
for general serializers in this thesis. Therefore, we will restrict our attention to a limited 


version called simple serializers. A simple serializer has the following restrictions: 


* The representation object (of type rep) for a simple serializer is a record 
that may only contain a single resource object and a fixed number of 
statically named queues and crowds. 


* All queue and crowd expressions are limited to selection of 
representation components 


* The guarantees on the enqueue statements can only test for qudieterpiy: 
crowd$empty, the logical and (x & y) of guarantees, and the logical or 
(x | y) of Bunrantecs. 


‘* Only enqueue and join statements may be executed while i in possession of 
the serializer object. 


* Each serializer operations must correspond exactly in number, name, and 
interface to a corresponding resource ‘Operation. No. statements: may: be 
executed inside a join, statement except to. invoke the corresponding 
resource operation, feturning its results if there are any. “This restriction 
also precludes the handling of exceptions. 


* Inside of a simple serializer operation, the return statement docs nol 
immediately return an object from the operation; as it would in.a-noraal 
operation. Instead, it is used to indicate the object te be returned when 
the serializer operation terminates. ‘This restriction is present to simplify 
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the semantic model in the next chapter. 


While the above restrictions may seem severe, they allow us to keep our 
presentation of details not associated with concurrency control to a reasonable level. 
Simple serializers are sufficient to solve the readérs-writers problem, as well as some 


more involved examples. 


In several places throughout the thesis we will indicate how extensions to 
simple serializers can be handled. These extensions include cases where more 
complicated computation must occur to determine the order. of processing requests, 
where the interface to the serializer differs from that of the ‘underlying resource, and 


where the serializer and the resource are implemented together. 


2.5 Using semaphores to implement serializers 


In this section we present a possible implementation of simpleserializers using 


fair semaphores and clusters. We do this for two reasons;. 


vitage 


1: To show that the serializer mechanism is realizable. 


2: To give further insight into the semantics. of serializers by giving a 
translation into a more commonly. understood mechanism. 


The semaphores that we use can be freely created, and obey a FIFO discipline when 
multiple processes request the same semaphore. We also describe the operations on the 


queue and crowd data types used in this implementation of serializers, 
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We assume that the semaphore data type has the following operations: 


create () returns (semaphore) 
returns a new semaphore with count = 0. 


P (S: semaphore) 
Atomically tests and sets the count of the given. stephore If count 
> 0, the count is decremented and the operation completes. If count 
= 0, then it stays 0 and the process performing the P.operation. does 
not proceed until the count becomes positive. Once the count 
becomes positive, the process waiting the longest Eectemenits the 
count and completes the P operation. 


V (S: semaphore) 
Atomically increments the count. Note that a P operation on an 
initially created semaphore must, wait si a corresponding V 


operation. 


We assume that the queue data type has the following operations: 


create () returns (queue) 
creales a new, empty, queue. 


eng (Q: queue, T: semaphore, G: guar) Agate 
adds the T, G pair to the queue, making the « qucue non- empty, The 
type of G, the guarantee expression, is assumed to be a predicate | to 
indicate whether the guaratitee is trie! 


deg (Q: queue) signals (empty) asi 
removes the head pair if the queue is not empty, otherwise signals 
empty. 


empty (Q: queue) returns (bool) . 
returns true if the queue is empty, false otherwise. 


get_guar (Q: queue) returns (guar) signals (empty) 
returns the guarantee evaluation procedure at the head of the queue 
if the queue is not empty, otherwise signals empty. Note that 
queue$get_guar(Q) can also be written as Q.guar. - 


get_sem (Q: queue) returns (semaphore) signals (empty) 
returns the semaphore at the head of the queue if the queue is not 
empty, otherwise signals empty. Note.that auevetert sem) can 
also be written as Q.sem. 


We assume that the crowd data type has the following operations: 


create () returns (crowd) 
returns a new, empty, crowd. 


insert (C: crowd, T: semaphore) 
inserts a semaphore into a crowd. 


remove (C: crowd,.T: semaphore) signals (absent) 
"removes a semaphore from a crowd Af present, otherwise signals 
absent. 


empty (C: crowd) returns (bool) 
returns true if the crowd ts empty, false otherwise. 


implementing a serializer as a cluster that u us 5s Semaphore is is: a t translation that 


has the mle eee = pet ae ae ce en 


1: The serializer becomes a cluster, and the representation object is 
extended to include a sem component; which is of type semaphore; and 
an eval component, which is of type sequence[queue]. The sem 
component is called the external SeMSDNOTS: and the eval component is 
called the queue list. 


2: The create operation initializes the external semaphore to.a newly created 
semaphore, and performs semaphore$V on it. The queue list X.eval ‘is 
initially the sequence of all ae in ik piece: 


3: Each operation that requires possession is given the allowing proog: 
semaphore$P(X.sem) 
T: semaphore := semaphore$new( ) 
where X is the name of the evt argument, and T is a unique local variable 
used to hold a newly created semaphore for the transaction. Tt is he to 


represent the process in queues and crowds. 


4: A return statement is translated into an assignment to a temporary 
variable (or a multiple assignment if multiple return. values are. present). 
This requires such variables to be declared in the’ prolog, and their values 
returned in the epilog. 


5: Each operation that requires possession. is given the following epilog: 
Eval(X) 
where the Eval procedure i is an internal opetution’ ised’ to’ select the next 
process to proceed, and will be detailed below. 


6: Each statement of the form: 
enqueue Q eee G 
is translated into: =~ a 
queue$enq(Q, 7, G') % place self in queue 


Eval(X) % release possession 
semaphore$P(Q. sem). % regain possession 
queueSdeqg(Q}). .. U% remove self from queue 


where Q is the queue to use in the expression, ‘T is the local semaphore 
variable introduced in the prolog, and G’ is a procedure:(desesibed’as - 


type guar) used to evaluate G.! 


7: Each statement of the form: 


join Cc 

Body 

end 

is translated into: we: a 

crowd$Sinsert(C, T) . % place self in crowd 
Eval(X) % release possession 
Body % execute body 
semaphore$P(X.sem) 4 regain possession 


crowd$remove(C, T) % ‘remove: setf. from crowd | 
where C is the crowd to: join, ahd: Body is the bedy of. statements to 


execute while not in possession. 


The Eval procedure selects the next process to receive possession. It first 
checks (in some unspecified oreet): the non- empty aueucs to determine whether the 
guarantee at the head of the queue is true, The first non- empty queue found with a true 
guarantee has V performed on its head semaphore, and Eval returns, If no non- empty 
queues are found with true guarantees, Vi is performed on the external Semaphore. Eval 


can be written as: 


7. A reader familiar with CLU may notice that we have taken some liberties in using G’, and have not 
fully defined the type guar. In general, it is necessary to use a closure of procedure and data to properly 
define G*. We have avoided these issues for the sake of simplicity; they do not affect our approach to 
concurrency control. 


Eval = proc (X: rep) 


4 examine all queves for true guarantees 
for q: queue in sequence[queue ]$elements(X.eval) do 
if queueSempty(q) then % if queue is empty. 


cont inue % then examine next queue 
end pees 
if q.guar(X) then % if guarantee is true 
semaphore$V(q.sem) % then allow that process 
return % to continue: execution 
end ae te | 
end 


% no non-empty queues have true guarantees. 
semaphore$V(X.sem) _. .% serve the. exteraal queve 


end Eval 


The above version of Eval always checks the queues in some particular order. It would 


be equally valid.to check the queues.in any. order, even if: non-detceministic. 


An example of how a serializer is implemented using clusters ang semaphores 
is shown in Figure 3. We have omitted the write operation, since there is li: tle 


difference from the read operation; and the Eval operation since its was s shown above. 


ey thet 


2.6 A comparison of serializers with monitors 


The unrestricted serializer construct has many similarities to the monitor 
construct. [Brinch Hansen 72, Hoare 74]. Both serializers: and monitors deal with 
synchronization by encapsulating details of concurrency control within a set of 


procedures. We present a brief comparison of the serializer and monitor constructs. 


Figure 3. Semaphore implementation of FIFO 


FIFO = cluster is create, read, write 


elist = sequence[ queue ] 


rep = record [rc: crowd, % readers’ crowd 
we: crowd, % writers’ crowd 
xq: queue, % common queue 
res: resource, % unserialized resource 
eval: elist, % the queue list 


sem: semaphore] % the external semaphore 


create = proc () returns (cvt) 

E: semaphore := semaphore$create( ) 

semaphore$V(E) 

Q: queue := queve$create() - 

return ( rep${rc: crowd$create (), 
we: crowd$create (),; 
xq: Q, 
res: resource$create (), 
eval: elist${Q], 
sem: E } ) 

end create 


read = proc (x: cvt, k: key) returns (vatue) 


% Prolog 
semaphore$p(x.sem) 
T: semaphore := semaphoreS$create() 
v: value 

% enqueue x.xq until crowd$empty (x.wc) 
queue$enq(x.xq, T, crowd$empty) 
Eval(x) 
semaphore$P(x.xq.sem) 
queue$deq(x.xq) — 


% join x.rc; return (resource$read as res, k)); end 
crowdSinsert(x.rc, T) : 
Eval(x) 


v := resource$read(x.res, k) 
semaphore$P(x.sem) 
crowd$remove(x.rc, 1) 

% Epilog 
Eval(x) 
return (v) 
end read 


% The write operation is not. shown. 


end FIFO 


below.® Except where noted, properties of the monitor construct are taken from 


[Hoare 74]. 


A serializer abstraction is intended to have.the same interface as the protected 
resource, while the monitor appears to be a lock on access to the resource. The 
serializer construct has the expressive power to be used as a lock, but the monitor does 
not have the expressive: power to mimic the resource (without serious loss of 
concurrency).? The serializer and monitor .constructs. both protect the underlying 
resource by controlling concurrent abcess 40 it: providing.that the only access is through 
the serializer or monitor. The serializer ‘construct further protects the underlying 
resource by allowing the programmer to prevent abcess to the resource except through 
the serializer. This protection can be achieved with monitors by having a data 
abstraction encapsulating a monitor, such that both the resource and the monitor can 
only be accessed through the data -abstraction.. Our ‘orefcwacs.6 to provide this 


appearance through a single construct. 


The serializer construct allows possession of the serializer object. to be released 
and regained in a controlled manner within a serializer operation. In the monitors 
presented. in [Hoare 74] there. is no such provision, - in an. extension to monitors 


{Lampson and-Redell 79] it is possible to write operations that donet Fequirc possession 


8. A comparison of an carlier version of serialiZers with moniters appears in [Hewitt and Atkinson 79]. 
An evaluation of serializers, monitors, and path expressions appears in [Bloom 79]. 

9. Extensions which alleviate this problem have been made for the moniters presented in 
[i_ampson and Redell 79}. 


of the monitor. This allows an operation to be written that requires possession of the 
monitor only for parts of the GP eanon: These protected parts are required to be 
invocations of monitor operations that require poses iot This solution i is slightly more 


complicated to use than the serializer fos statement, but is otherwise similar. 


Serializers use explicit aes at the point in the procedure: where a 
process waits ona queue. That guarantee is true when the process proceeds (providing 
that removing ‘the process from the.queue did not. change: the guarantee). Monitors also 
have first-in-first-out queues (called conditions), but the expressions that determine 
which queues are to ‘be serviced next are distributed throughout the various iain 


of the monitor, which complicates the verification task. 


As mentioned briefly above, there..is-a.basic, difference the use. of queues in 
monitors and serializers... Processes in the same queue in serializers can be waiting, for 
different guarantees. Although the same effect.can be,achieved in monitors, it usually 


requires extra code to do so, and is difficult to write and understand. - 


The serializer construct, ‘like the CL U cluster construct, supports sets cof 
objects belonging to an abstract type. The monitors proposed in [Hoare 74] tend to 
support one-of-a-kind Sneipsulauon This di ference i is more a reflection of the base 
language used than a basic difference between serializes and monitors. ‘We mention 


See 


this difference because we believe that supporting sets of objec i is a 1 beiter choice to 


make, since there is more potential concurrency ina Sytem salient data is 5 partitioned 


into separate Objects. 


2.7 Opportunities for optimization 


One objection that might be raised to serializers is that they are inherently 
inefficient: at every release of possession the queues must’ be checked to determine 
whether the condition at the head of each queue is satisfied.!° For this objection we 


have two answers: 


1: It is unlikely that the evaluation of such conditions will be expensive 
compared to the execution of resource operations. : 


2: In the event of the guarantee checking being a significant cost in a 
. program, optimization. techniques are especially: appneanne | in this. limited 
context. 


As an example of how we might optimize the checking of guarantees, consider 
the FIFO example. When a writer leaves the writers crowd, it is casy to prove that both — 
the readers-and writers crowds are empty. This knowledge allows an optimizing: 
compiler to immediately dequeve the next transaction in-the quene (if any} whenevera. 
writer completes. In such a case, no guarantee evaluation takes place. When a reader 
leaves the readers crowd it is casy to prove that the writers awd is still empty, which 
-. allows the compiler to simply check the head of the queue for a 1 reader, thus avoiding 
any more complex evaluation. Whenever a writer joins the wiiters crowd all guarantees 3 
are known to be false, and do nat need to be checked at all. In short, we have shown 


that intermediate steps of the wGATION program can lead to sufficient in formation to - 


10. A similar objection is actually raised in [Hoare 74, p. 556). 
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perform optimizations that can significantly reduce overhead for checking guarantees. 


We have advocated designing, verifying, and implementing serializers and 
data abstractions independently. This independence can lead (especially in CLU) to 
many levels of procedure calls, where each procedure performs an extremely small part 
of the computation. When the overhead for procedure calls costs on the same order as 
the rest of the computation, it becomes desirable to substitute the bodies of procedures 
for their invocations [Atkinson 76, Scheifler 77]. For serializers in the style we have 
advocated, it is generally both simple and beneficial to perform this substitution. We 
note that the simplicity of the substitution is greatly aided by our initial requirement 


that the serializer present the same interface as the underlying resource. 


se 


3. Semantic Model 


In this chapter we present an abbreviated semantic model. for concurrent 
execution of programs, and use. it to define serializer semantics. In the next chapter, we 


use the model to define a smalt specification. language for serializers. 


The semantic model we use to define serializers is intended to be embedded 
within a larger semantic model, just as the serializer construct is embedded i in a larger 
programming language. We will not be concerned initially with which larger model is 
used, although we will return to the issue later. Whatever larger model is used, there 


must be support for shared objects, side-effects, and concurrency. 


We will first give an overview of the semantic model for serializers, assuming a — 
particular larger semantic model. Then we discuss the various components of he 
model in detail, Then we give the meaning of the serializer construct by giving 
predicates that all scrializers must satisfy. Finally, we discuss the role of induction in 
the serializer model, and outline how the model might be embedded in a different 


larger semantic model based on message-passing between processes. 


3.1 Overview of serializer semantics 


Informally, the text of a serializer iS set of statements that describe what 
happens when serializer operations are executed in a aien with concurrent processes. . 
To give the semantics of the seraliace construct, we eauite : definition: of “serializer 
operations", a definition of "execution", a definition of "process", and a. definition of 


“what happens". 


The model we choose can be viewed as an interpreter. Each procedure is 
represented by a seach composed of basic instructions that indicate which actions to 
perform and arcs between the insthaclions to indicate the order of execution. There isa 
global state;‘consisting of a set of shared. objects.and.a set of processes. Each process has 
a local state, which. includes a set of local objects, a stack of procedure activations, and a 
program counter that indicates the instruction that.the process is to execute next. Each 
instruction represents some basic action. Executing.an instruction modifies the global 
or local state. The execution of an instruction always indicates the next instruction in 
the proccss by modifying the program ‘counter. A process where. the next instruction is 
permitted to-oecur is-called active. -Executing.certain instructions may cause a process Lo: 


become inactive until certain conditions hold. 


For simple serializers, the only components of the global state modelled are 
the state of the queues and crowds for the serializer object, and the state of serializer 
possession. The only component of the local state modelled is the program counter 


within a serializer operation. 


The interpreter proceeds by choosing an active process, and executing the 
instruction indicated by the program counter of that Process. Although the choice of 
process is non-deterministic, no process that ts ‘active may be indefinitely denied. 


execution. We call the sequence of instructions executed by the interpreter a history. 


“We can give the semantics of this informal modet through a predicate that 
takes a history, an initial global memory state, an initial set of processes (and their local 
. States), and a set of graphs representing the procedures in the system, and returns a 
boolean indicating whether the history could be produced by the interpreter we have 


described. We will call this predicate the global legality predicate. 


In this thesis we are discussing a single fanguage construct. In this context, 
presenting a complete definition for a language would occupy more'space and attention . 
than it merits. The semantics of a language construct.can be defined through:a partial 
legality predicate that partially..determines the global legality predicate. For the 
serializer construct, this predicate is. false for histories. that are prohibited due to 
serializer semantics, and true for others. We will not presenta definition: of a larger. 
language, nor formally state the. interactions between. the serializer construct. and the 


other inguage features. 


3.2 Nodes 


In defining what is meant by “execution of serializer operations”, we first need 
to define a representation for an operation and its associated data. Since we are dealing 
with only one serializer object at a time, it is convenient 18 regard the serializer 
operations and the serializer object as being inextricably bound together into a single 
unit. For brevity in this chapter, we: will use the term serializer object to refer to this 


unit. 


Each serializer’ operation (bound to an associated: serializer object) is 
composed of nodes. A node is just (informally sacaking) an ‘ristrichion at some location 
in a program with its associated data. A node graph is used to represent a serializer 
operation, where the arcs in the graph represent sequential exccution: For simple 
serializers, the node graph is degenerate, since there is a linear order to the nodes. We 


have used the term graph-to case the discussion. of extensions to this model. 


The following kinds of nodes are involved with synchronization in a simple 


serializer. At such a node, possession of the sertalizer object may be gained or released. 


enter (opcration_name(formal_arguments)).. Vhis , nade. represents. the 
initial entry to an operation that requires possession of the serializer 
object. After this node. is executed, the executing process has 

exit: This node represents the epilog to an operation that. requires 
possession. Executing this node releases possession. 


enqueue (queue, guarantee): This node represents the first part of an 
enqueue statement. Executing this node places the process in the 
specified queue with the specified guarantee and releases possession. 


dequeue (queue, guarantee): This node represents the:second part of the 
enqueue statement. Executing this node regains possession and 
removes the executing process from the queue. 


join (crowd): This node represents the start of the join statement. 
Executing this. node places: the process.in the crowd and releases 
possession. 


leave (crowd): ‘This node represents the end of the join statement. 
Executing this node. regains possessian through the external queue 
and removes the process from the crowd. 


The following kinds of nodes are used for other primitive actions that can 
occur in a simple serializer. | 
invoke (invocation): This node represents the termination of cxecution of 


the specified invocation. For simple serializers it will only appear 
once, and must appear in the body of a join statement. 


return (invocation): As with the iavoke node, the return node represents 
_ the termination of execution of the specified invocation. Executing 
the return node also: designates the object to ve apna when the 

- seriatizer operation t terminiites at abies icon iy: 


The use of invoke and return nodes in tie sctializers is limited to showing where the 


operations of the underlying resource are called. 


Each node N has the following structure: 


* N.kind - an identifier (one of enter, exit, enqueue, dequeue, join, leave, 
invoke, return) indicating the kind of node. 


* N.next - empty for exit nodes; otherwise the next node in the execution 
sequence. Note that the next node for any return node is an leave node if 
the return is performed while in a join statement, otherwise the next node 
is a leave node. 


*N.mob - for enqueue and dequeue nodes, the queue used; for join and 
leave nodes, the crowd used; otherwise empty. 


* N.expr - for enqueue and dequeue nodes, the condition to guarantee; for 
return and invoke nodes, the expression to evaluate; for an enter node, 
the operation name and its formal arguments; otherwise empty. Note 
that for an invoke or return node the information about which procedure 
is executed and which arguments are used is contained in the expression. 


*N.match - for an enqueue node, the corresponding dequeue node; for a 
join node, the corresponding leave node; otherwise empty. 


The transformation of a serializer operation to nodes will be given by example. 
Suppose we have the following operation in a serializer: 


change = proc (x: cvt, d: data) returns (value) 
enqueue x.q until crowd$empty(x.c) 
join x.c 
return (resource$Schange(x.r, d)) 
end 
end change 


The node graph for the above operation can be represented as:. 


Ni: 
N2:; 
N3: 
W4: 
N5: 
N6: 
N7: 


enter (change(x, d)) 

enqueue (x.q, crowd$Sempty(x.c)) 
dequeue (x.q, crowdSempty(x.c)) 
join (x.c) 

return (resource$change(x.r, 4) 
a (x.c) 

exit 


In the above graph, Nl.next = N2, N2.next = N3, and so on. N7.next is 


empty. The queues, crowds, and expressions are indicated. 


N2.mob = N3.mob = xq 


N4.mob = N6mob = xc 


N2.expr = N3.expr =  crowd$empty(x.c) 


The reader should be cautioned that the description we have given for nodes 


and node graphs is incomplete. We have not discussed conditional statements, 


assignment, exceptions, or iteration. In later chapters: we will describe how extended 


node graphs would be handled. 
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3.3 Events 


Informally, an event is the completion of execution of a node in a process. For 


our purposes, the important features of an event are: 


* An event is atomic. An event takes no time to occur, although the 
amount of time between events is always positive and finite. 


* An event is associated with a single node of a serializer. 


* An event is associated with a single “process”. We assume that the reader 
has some intuitive idea of process. We will introduce a more exact 
definition of a specialization of the process notion in the next section. 


It has been proposed [Greif 75] that an event is a state transition. The state of 
a simple seria‘izer consists of the state of the serializer queues (not including the 
external queue), the state of the serializer crowds, and the state of the serializer 
possession, Only the simple serializer events (enter, exit, enqueue, dequeue, join, leave) 
change the state of possession. Changes in possession that do not alter internal queues 
or crowds result from enter and leave events. Changes to internal queues result from 
enqueue and dequeue events. Changes to crowds result from join and leave events. We 


will return to this point in a later chapter. 


In a full semantic model we would have to show where an invocation started 
and where it terminated. For simplicity, we have chosen to not represent the event that 
marks the start of an invocation. ‘The invoke and return events are sufficient to indicate 


where the resource operations are called, which is all that we need at this point in our 
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discussion. 


A dequeue cvent marks a change in state of the indicated queue, and a change 
in the possession of the serializer. A dequeue event for some process will not occur until 
after the corresponding enqueue event, and not until that process is at the head of its 
queue and the guarantee evaluates to true. The evaluation of guarantees takes place 
immediately prior to every. event that releases possession (enquene, join, and exit events 
release possession). For any event E that retfeases posscssion, we will assume that 
evaluation of the guarantces takes place between E and the serializer event immediately 
preceding E. For simple serializers, where the guarantees are limited to side-effect free 
evaluation of expressions involving the serializer state, no further events need to be 
introduced to represent the evaluation of guarantees. If more involved expressions are 


allowed, events representing such evaluation mus! be introduced. 


3.4 Transactions 


For a serializer, a (ransaction is a sequence of serializer events that occur for 
some process in the exccution of a serializer operation for some serializer object. ‘The 
order of events in a transaction is the same as the order in which those events occur in 
the execution of the serializer operation. Each enter event for some serializer object is 
the first event in some transaction, and cach exit event is the last event in some 
transaction. We assign a unique fransaction identifier at the occurrence of an enter. 


event. 
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A transaction may also be viewed as a segment of a process. There may be 
many transactions involving a serializer object for any particular process, but a 
transaction can only belong to a single process. The intent of transactions is to capture 
only the amount of detail about a process necessary to define serializer semantics. 


Where we formerly used the term process, we will now use the term transaction. 


Now that we have identified events as being associated with transactions and 
nodes, it is notationally convenient to give events a structure. Each event E has several 


components: 
* E trans - the transaction identifier for the event. 


* E.node - the node associated with the event. 


* E.kind - the same as E.node.kind. 


We can associate possession of the serializer object with a transaction by 
noting that if there have been more gaining than releasing events for some transaction 
in some finite history (the difference can only be 0 or 1), then the transaction has 
possession of the serializer from the last releasing event for that transaction up to the 


last event in that history. 
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3.5 Histories 


For a serializer, a history is a sequence (possibly infinite) of events that 
represents all events that occur for a particular serializer object. For a given serializer 
object, there are inf nitely many possible histories, depending on 1 the requests sent to 
that alice object and on the arbitrary choices possible i in sclecting dequeue events 


when several queues are ready. 


A history can be viewed as being some interleaving of the transactions 
involving a serializer object. Every event in a history also belongs to some transaction. 


The reverse is not true, our model includes histories with incomplete transactions. . 


Serializer semantics is defined by stating which histories-can be produced for 
any given serializer object. We define a predicate that, given a representation of 
serializer code and a serializer history, will be true if and only if the history could be 
produced by the serializer. A history that satisfies that predicate is called a legal history — 
for that serializer code. A more complete definition of a legal history occurs later in this 


chapter. 
We assume that the following functions are defined on'serializer histories: 


Finite(H) 
is true if the history is finite; otherwise false. 


Size (H) 
returns the number of elements in au if H is finite: otherwise -is 
undefined. 


Index_set (H) 
if H is infinite, returns the set of positive integers; otherwise returns 
the set of integers {N | 1 <= N <= Size(H)}. 


Nth (H, N) 
returns the Nth element of H if N € Index_set(H); otherwise is 
undefined. 


Head (H, N) 
returns a prefix of H that is the first N elements of H, provided that 
N € Index_set(H); returns the empty sequence if N is 0; otherwise is 
undefined. 


For simplicity, we have chosen to model only those operations that accept a 
serializer object as an argument. We assume that the serializer object is initially in some 
initial state, such as that obtained by executing its create operation: the resource object 
is in its initial state, no transaction has possession, and all queues and crowds are empty. 
The model we have presented is only sufficient to represent operations where 
possession of the serializer object is gained. For example, the FIFO serializer presented 
in the previous chapter has three operations; the model we have presented is only 


sufficient to represent two of them: read and write. 


3.6 Definitions 


Predicates will be defined in a dialect of first-order predicate calculus. 
Functions are defined using a similar syntax, but avoid the use of quantifiers. We call 


this language the definition language, and will refer to it as such in later chapters. 


Many of the following definitions are more easily expressed if we have a 
notation for conditional expressions. The éapretsion “if X then.Y else Z" is taken to be 
Y if X is true (even if Z is undefined), and Z if X is false (even if Yis undefined), and 
undefined if X is undefined. We also use the “elseif” extension to this notation, as in 
CLU, to allow convenient syntax for multiple cases. “In cases where the “else” clause is 
omitted, "else true” is assured (which implies that only boolean conditional expression 


may omit the “else” clause). 


_ Many of the functions and predicates given below are defined only for finite 
histories. In our definitions, these functions and predicates are never applied to in finite 


_ histories, so there is no need to define them for those cases. 
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Event E occurs in history H if there is some integer index N such that E is the 
Nth event of H. Event El precedes event E2 in history H if both El and E2 occur in H, 


and the.index where El occurs is less than the index where E2 occurs. 


Occurs (E, H) = 
31 € Index_set(H): E = Nth(H, I) 


Precedes (El, E2, H) = 
a1, J € Index_set(H): 
1<J& El = Nth(H, I) & E2 = Nth(H, J) 


Note that we have assumed that an event can only occur once in a history. This is 


implied by later definitions. 


AS a notational convenience, we introduce. the predicate Same_trans(H, I, J), 
which is true if the Ith and Jth events in history H are from the same.transaction. The 


predicate is undefined if the integers | or J do not belong to Index_set(H). 


Same_trans (H, |, J) = 
Nth(H, 1).trans = Nth(H, J).trans 
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We often nced to express the idea that a particular event, or all events for a 


given node, cannot occur between two given events. 


Excludes (El, E2, E, H) = 
Precedes(E, El, H) | Precedes(E2, E, H)| E = EL] E = E2 


Excludes_node (El, E2, N, H) = 
v 1 € Index._set(H): 
if Nth(H, 1).node = N 
then Excludes(E1, E2, Nth(H, I), H) 


A slightly more complicated predicate will be needed to specify a more 
general — exclusion predicate (to be | ied in later: | chapters). 
Node_excludes_node (N1, N2, N, H) is true iff no event for a given node N can occur 
between any two -events El and E2, where El:node = Nl, E2.node = N2, and 


El.trans = E2.:trans. 


Node_excludes_node (N1, N2, N, H) =; 
v I,J € Index_set(H): 
if ( Nth(H, l).node = N1 
& Nth(H, J).node = N2 
& Same_trans(H, |, J)) 
then Excludes_node( Nth(H, #), Nth(H, J), N, H) 


Intuitively, Node_excludes_node(N1, N2, N, H)} expresses the restriction that no. event 
gencrated. by node N occurs between events generated by nodes NI and N2, where the 


events from N1 and N2 belong to the same transaction. 
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We are often interested in the last event of a finite history, or in a history that 
lacks only the last event of a given finite history. The functions Last and Front are used 


for notational convenience. 


Last (H) = Nth(H, Size(H)) 


Front (H) = Head(H, Size(H) - 1) 


Certain events gain exclusive possession of the serializer, while other events 
release possession of the serializer. Still other events do not change possession. 
Gains(E) is true only if the event E gains possession, while Releases(E) is true only if E 
releases possession. 


Gains (E) = 
E.kind = enter | E.kind = leave | E.kind = dequeue 


Releases (E) = 
E.kind = exit | E.kind = join] E.kind = enqueue 
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A finite serializer history is busy if its last event gained possession of the 
serializer, or if its last event did not release the serializer and the history before that 


event was busy. 


Busy (H) = 
if Size(H) = 0 then false 
elscif Releases(Last(H)) then false 
else Gains(Last(H)) | Busy(Front(H)) 


The functions Qsize and Csize return the number of transactions using a 


queue or crowd given the queue or crowd and a finite history. 


Qsize (Q, H) = 
if Size(H) = 0 then 0 
elseif Last(H).kind = enqueue & Last(H).mob = Q 
then Qsize(Front(H)) + 1 _ 
elscif Last(H).kind = dequeue & Last(H).mob = Q 
then Qsize(Front(H)) - 1 
else Qsize(Front(H)) 


Csize (C, H) = 
if Size(H) = 0 then 0 
elseif Last(H).kind = join & Last(H).mob = C 
then Csize(Front(H)) + 1 
elseif Last(H).kind = leave & Last(H).mob = Co  - 
then Csize(Front(H)) - 1 
else Csize(Front(H)) 
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In certain serializer specifications, the rank of an event is important. The rank 
of an event E is an integer that represents the order of E relative to other events 
occurring at Enode. The first event to occur at 4 node has rank 1, the second has rank 

_2,and soon. The rank of an event that does not eect iit a history is 0. | 
Rank (H, E) = 
if Occurs(H, E) 


then 1 + Rank_scan(H, E, 1) 
else 0 


In defining Rank, we made use of Rank_scan(H, E, |), which returns the 
number of events occurring in H at or after event Nth(H, I) and before E with the same. 


node as E. 


Rank_scan (H, E, I) = 
if Nth(H, I) = E then 0 
elseif Nth(H, 1).node = E.node 
then 1 + Rank_scan(H, E, 1+ }) 
else Rank_scan(H, E, 1+ 1) 
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3.6.1 Evaluation of guarantees 


Whenever a serializer is released, the guarantees of the non-empty queues are 
evaluated. The following functions define such evaluation given a finite history and an 
expression to be evaluated. The notation {G} is used to represent the expression G 
occurring in serializer code, and distinguishes the expression from our definition 


notation, since the syntax for expressions and definitions is often similar. 


Eval is defined by cases, each case being based on the syntax for boolean 
expressions. For simple serializers, Eval returns a boolean value, since guarantees are 


limited to boolean expressions involving tests on the emptiness of queues and crowds. 
Eval (H, {G1 & G2}) = Eval(H, {G1}) & Evai(H, {G2}) 
Eval (H, {G1 | G2}) = Eval(H, {G1}) | Eval(H, {G2}) 
Eval (H, {~ G}) = ~Eval(H, {G}) 
Eval (H, {crowd$empty(C)}) = Csize(Var({C}), H) = 0 
Eval (H, {queueSempty(Q)}) = Qsize(Var({Q}), H) = 0 
Eval (H, {false}) = false 
Eval (H, {truc}) = true 
The Var function (in Var({Q}) and Var({C})) is a mapping from syntactic 


expressions for queues and crowds to some semantic representation for queues and 


crowds. We require that the mapping. produced by Var is the same mapping that is 
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used to produce the N:mob component of any nede N in the history H. 


The above definition of Eval is tailored to the needs of defining the semantics 
of simple serializers. There is no provision for local variables, which would be 
transaction specific. There is no provision for guarantees with side effects, exceptions, 
or non-termination, which would require the use of events to mark’ the state transitions. 


Further, such provisions would also complicate the definition of the Var function. 


3.6.2 Legal histories 


A history is legal if it can be produced by some execution of a serializer. 
Legal(H, S) takes a history and a set of nodes that represent the code for a serializer, 
and returns true if the history could have been produced from the serializer code. A 
legal history must be composed of legal steps. That is, each prefix of the history can 
only be followed by an event that represents a permitted state transition of the 


serializer. 
For a finite history H to be legally followed by the event F; the following rules 


must be satisfied: 


* For E to gain possession of the serializer, then there can be no transaction 
in possession of the serializer (~ Busy(H)).. 


* If there is a transaction in possession of the setiulizer, thet E must'belong 
to that transaction. 


- 62+ 


* If E is a dequeue event, its transaction. must-be at the head of its queue 
and the guarantee must be true. 


* If Eis an enter or leave event, there may be no queues such that the front 
transaction in the queue has a true guarantee, : 


* All events from a single transaction must occur in the order dictated by 
legal execution of the code for the operation executed by that transaction. 
In parueutar, an enter event must be the first event in its transaction. — 


Note that there are no restrictions explicitly involving join and exit events. The only 
restrictions that we impose for these events are expressed by the requirement for “legal 


execution" of the node graph. 


The above conditions lead to the following definitions of Legal and 
Legal_step, where H is a history, and S is the set of enter nodes for the operations.of the 


serializer that require possession. 


Legal (H, S) = 
Vv N. € Index_set(H): Legal_step(Head(H, N-1), Nth(H, N), S) 


Legal_step (H, E, S) x 
( (if Gains(E) then ~Busy(H)) 
& (if Busy(H) then:Last(H).trans = E.trans) 
& (F.kind = dequeve D1 cgal_ dequeue(H, E)) . 
& (if Ekind = enter | E.kind = " Keave: then None ready) 
& Legal_transaction_step(H, E) 
&(F.kind = enter D E.node € Nodes(S))) 
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The event E is a legal dequeue event after the end of history H if the guarantee 


is true, and the corresponding enqueue event is is at the head of its queue in history H. 


Legal_dequeue (H, E) = 
( Eval(H, E.expr) 
& 31 € Index_set(H): 
( Nth(H, I).node.next = E.node 
& Nth(H, 1).trans = E.trans 
& Head_enqueue(H, 1) )) 


The transaction for the enqueue event Nth(H, I) is at the head of its queue if 
Nth(H, I) is the last event in H for the transaction, and every other enqueue event 
occurring in H before Nth(H, I) has a corresponding dequeue event. 
Head_enqueue (H, I) = 
( In_queue(H, 1) 


& v J € Index_set(H): 
if J < 1 then ~In_same_queue(H, [, J)) 


In_queue¢H, 1) is true only if Nth(H, 1). is an enqueue event that is the last event in H 


for its transaction. 


In_queue (H, 1) = 
( Nth(H, !).kind = enqueue 
& WJ € Index_set(H): 
if} > 1 then ~Same_trans(H, I, J) ) 


In_same_queue(H, I, J) is true iff Nth(H, 1) and Nth(H, J) are enqueue events that are 


the last events in their transactions and the transactions are in the same queue. 


In_same_queue (H, I, J) = 
( In_queue(H, 1) 
& In_queue(H, J) 
& Nth(H, 1).node.mob = Nth(H, J).node.mob ) 


None_ready(H) is true if for a particular finite history there is no explicit 
serializer queue such that the front transaction in the queue has a guarantee that 
evaluates to true. This predicate is used to define the priority of explicit queues over 
the single external queue of a serializer. 

None_ready (H) = 
Vv 1 € Ipdex_set(H): 


if Head_enqueue(H, 1) 
then ~Eval(H, Nth(H, 1).node.expr) 


An event E can be a legal step after some history H only if it can be produced 
by sequential execution of some transaction. There must not be an event in H with the 
same transaction and the same node as E; and if E is not an enter node, then there must 
be an event in H from the same transaction as E that results from executing a node for 


which E.node is the next node. 
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Legal_transaction_step (H, E) = 
(v 1 € Index_set(H): 
(if Etrans = Nth(H, I).trans 
then E.node # Nth(H, 1).node) 
&ifEkind + enter 
then 3 1 € Index_set(H): 
( Etrans = Nth(H, !).trans 
& E.node = Nth(H, 1).node.next) ) 


3.6.3 Complete histories 


The set of legal histories for a serializer includes historics where transactions 
have been started but not completed. Any finite legal history where the serializer state 
requires further events to occur is termed’ incomplete. All other legal histories are 
complete. A complete finite history is one where no further events are required to 


occur. Events are required to occur according to the following rules: 


The serializer specification language will be interpreted as defining 
specification predicates on complete histories. Serializer code is said to mect its 
specifications if the specification predicates are true for every complete history of that 


code. 
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For a complete history, all events that are required to occur in the history must 


occur. 


* Whenever a releasing event occurs and there are ready queues, a dequeue 
event from one of those queues is required. Therefore, if H is finite, and 
the last event in H released possession, then H is only complete if no 
queues are ready. 


* For every event that gains possession of the serializer, a corresponding 
event that releascs the serializer is required. For simple serializers, every 
gaining event will be followed by a releasing event. Note that this 
condition implies that if H is finite and not empty, then Last(H) was a 
releasing event. 


’ 


* For every join event, a corresponding leave event is required. We assume 
that every operation of the underlying resource used in a join statement 
will terminate. Such an assumption is part of a modular proof of 
termination for programs involving serializers. 


These conditions lead to the following definition for Complete, where H is a history for 
some serializer, and S is the set of enter nodes for operations of that serializer that 
require possession. 
Complete (H, S) = 
( Legal(H, S) 
& (if Finite(H) then None_ready(H)) 


& Gain_complete(H) 
& Join_complete(H) ) 
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Gain_complete(H) is true if for every gaining event there is a corresponding 


releasing event that occurs after the gaining event. 


Gain_complete (H) = 
Vv I € Index_set(H): 
if Gains(Nth(H, 1) 
then 3 J € Index_set(H): 
Corresponding_release(H, |, 1) 


Corresponding_release (H, I, J) is true if Nth(H, J) is the releasing event that 
corresponds to the gaining event at Nth(H, I). A releasing event corresponds to a 
gaining event if both events are in the same transaction, and there are no intervening 
releasing events for the same transaction. 

Correspording_release (H, I, J) = 
( Release_follows(H, I, J) 


& VK € Index_set(H): 
ifK <J then ~Release_follows(H, I, K) ) 


Release_follows (H, I, J) is true iff Nth(H, J) is a releasing event that follows 


the event Nth(H, 1); and belongs to the same transaction as Nth(H, 1). 


Release_follows (H, 1, J) = 
1< J & Same_trans(H, 1, J) & Releases(Nth(H, J)) 
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-Join_complete(H) is true if every join event has a corresponding: leave event. 
A leave event corresponds to a join event iff it-belongs to: the same: transaction as the 


join event and there are no intervening leave events for the same transaction. 


Join_complete (H) = 
Vv 1 € Index_set(H): 
if Nth(H, [).kind = join 
then 3J €Index_set(H): Bae aa 
( Leave_follows({H, I, J) 
& V K € Index_set(H): 
fK<S 
then ~Leave follows, 1, .K)) 


Leave_follows (H, |, J) is true iff Nth€H; 4) is a heave event that foltows the 
event Nth(H, I), and belongs to the same transaction as Nih(H, D. 


Leave_follows (H, I, J) = 
1< J & Same_trans(H, I, J) & Nth(H, d)-kind = leave 


3.7 Serializer Induction 


In CLU, a cluster that implements a data type ap so by providing operations 
that manipulate objects of a representation type. For, every abstract object, there isa 
representation object. In designing and verifying clusters, it has been found to be 
useful to make use of a representation invariant [Guttag, Horowitz and Musser 78] that 
must hold for all objects supported by the cluster. This representation invariant should 


be true whenever a representation object is created, and it should be maintained by all 
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operations. 


To prove that the representation invariant holds, we need to use induction on 
the sequence of operations performed. The induction principle we use is that if P is 
true at the start of the abstract object's lifetime, and assuming P for an object at the start 
of an operation implies that P is true at the end of the operation, then P is true of that 
object before and after every operation. As in [Guttag, Horowitz and Musser 78}, we 


will call this data type induction! 


To show the soundness of data type induction, we need to show that if P is 
true of an object after any operation of the cluster, then P is true of the object before 
any other operation of the cluster, provided that ‘here were no intervening operations 
of the cluster. Informally, to use data type induction using some predicate P, it should 
not be possible for actions of other programs te:make:P invalid. It is possible in CLU to 
write clusters such that data type induction can be used to prove reasonable predicates 
about theif objects, A cluster with this property is said to have an isolated representation 
[Atkinson 76]. While the cluster constrict is mot strictly ‘necessary if one wishes to- use: 


dita type induction, it facilitates the determination of an isolated representation. 


As presented in this thesis, the serializer cdnstruct is quite similar to the cluster 
construct. Both can implement abstract types, and doth do so by manipulating objects 


of a representation type through operations that can have sole access to the 


11. Also know as generator induction in |Wegbreit and Spitzen 76]. 
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representation objects. Since serializers provide the same kind of representation 


protection as clusters do, we can use data type induction, in part, to verify serializers. 


We call the application of data type induction to histories serializer induction. 
For any complete history H, serializer induction can be expressed as: 
if 
( P(Head(H, 0)) 
& Vv I,J € Index_set(H): 
(if (Gains(H, 1) 
& Corresponding_release(H, |, J) 


& P(Head(H, I-1)) 
then P(Head(H, J))) ) 


then 
Vv K € Index_set(H): 
if Gains(Nth(H, K)) then P(Head(H, K-1)) 
The predicate P is intended to be defined on finite histories where no transaction is in 
possession of the scrializer at the end of the history. 
History induction is applicable for any serializer where the predicate P will 
hold from the event where possession is released to the next event where possession is 


guined. We can express this condition as: 


Vv I,J € Index_set(H): 
if ( Gains(Nth(H, 1)) 
& Releases(Nth(H, J)) 
& Nth(H, J).node.next = Nth(H, 1).node 
& P(Head(H, J-1)) ) 
then P(Head(H, 1)) 


We call this the isolation condition. Just as the cluster construct facilitates but does not 
fully enforce an isolated representation, the serializer construct does not necessarily 


enforce the isolation condition. 


The serializers we will be specifying and proving ‘satisfy. the isolation 
condition. In. view of this, there is no provision in the histories for events that occur 
external to serializers. We have not provided for situations that we have been unable to 


prohibit in the programming fanguage, but believe to be bad practice. 


An example of serializer induction is the use of a representation invariant for 
the FIFO readers-writers problem presented in the previous chapter. A simple 
invariant for an object X of type rep for any finite history H is: _ 

Csize(X.re, H) = 0 | Csize(X.we, H) = 0 
While this invariant is not the strongest we can prove, it is a useful property that can be | 


proven simply. 
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As a reminder, the code for the read operation is (briefly): 


enqueue x.q until crowd$empty(x.wc) 
join x.rc; ... end 


while the code for the write operation is: 


enqueue x.q until crowd$empty(x.wc) & crowdSempty (x. rc) 
join x.wc; ... end 


Informally, we can prove the invariant by cases. First, suppose that we have 

Cl = Csize(H, X.rc)>0D Csize(H, X.we) = 0, 

C2 = Csize(H, X.wc) > 0 D Csize(H, X.rc) = 0 
where the history prefix is understood. Since Csize always: results in a non-negative 
integer, the condition Cl & C2 implies the invariant. Initially; both crowds are empty, 
so: the invariant is trivially:true. To prove Cl, we-assume.that-€1 is true immediately 
prior to some gaining event, and show that: it js maintained: immediately after any 
ial event. An examination of me code shows that the only sequence of events 
that can increase Csize(X. wc) is where some writer dequeues and j joins the writer crowd. 
Therefore, the only way that Cl could be false is to allow some writer to dequeue when 
Csize(X.rc) > 0. However, the guarantee for the writer fealenction prohibits the event 
from occurring until Csize(X.rc) = 0. ‘Therefore, Cl is: maintgincd. ‘Condition C2 is 


proved similarly. ‘Therefore the invariant is maintained... _- 


3.8 Comments on enter and eave events __ 


One simplification made in the model is based on the use of enter and leave 
events. A reasonable requirement on enter events is that they will occur if they have 
been requested. The only requirement -that we have on leave events is that they will 
eventually occur if the corresponding join has. occurred. Yet after completing the 
resource operation, the leave event must be requested, since some other transaction may 
be in possession: The simplification we have made is not to represent requests for'enter 


or leave events as separate events. 


One requirement that this places on serializers is that code executed while a 

transaction has possession of the serializer must terminate, since otherwise a request for 
ees 2 Pee Behan A co 

possession could not be satisfied. Termination while in possession is trivially satisfied 


for simple serializers. 


We have also assumed that there is sonie scheduling discipline on requests for 
possession of the serializer so that a request for an enter or leave event will not be 
forever delayed by other such requests. A FIFO discip{ine on all such requests may be 
overly strict in some systems, and we do not require it. Any discipline that guarantees 
service to requests for possession will be satisfactory. We make no attempt to prove this 


requirement in general. 


Adding specific events to the model to indicate when enter and leave events 
have been requested is only necessary to represent undesirable cases such as 


non-termination while in possession, or a pathological scheduler. Further, it is not 


Pay fe 


reasonable to include such events in the specifications: or proof techniques, since their 


order of occurrence is not affected by possession of the serializer object. 


po 


3.9 Message passing semantics 


The model we have presented in ‘this chapter has been deliberately 
incomplete. The larger semantic model we have assumed’ uses procedure calls and 
processes, and is well-suited for describing the use of serializers in a system where 
multiple processes communicate through shared memory. While having a certain 
intuitive appeal, particularly to those familiar with monitors, the techniques we have 
used (and will use) are applicable when a larger programming language and larger 


semantic model are used. 


In this section we will sketch a model based on message passing. Such a model 
_ has been proposed by various people [Greif and Hewitt 75, Hewitt and Baker 77, 
Good, Cohen and Keeton- Williams 79). A similar mode! i is used to describe distributed 
systems [Svobodova, Liskov and Clark 79, Liskov 7). We believe that the structure of 
serializers is quite useful in or ganizing Programs in these distributed systems, and will 


address some further implications of serializers in such an environment in our 


conclusions. 


In the message-passing model, separate entitics communicate by passing 
messages rather than by payne memory among many processes. or course, when the 
same physical entity receives Messages from various SOUICeS, the effect of a shared 


memory is achicved. We can think ofa wanatiiee Spiel ws one such entity, the resource 
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object as another entity, and the originators of messages to the serializer as other 
entities, In such a model, serializer objects are message switchers: They affect when a 


message gets passed to a resource, but not the message itself, Nor its reply. 


We. imagine that seraliders are used in'a programming language that supports 
a logical network, where there are logical sites, each of which has its, own. local objects. 
Each site can communicate with another site only by sending messages to that other 
site. We assume that each site. can send. messages to any other site without regard to 
physical connections. ; Unlike physical sites. in a network, logical ‘sites can. be freely 


created at relatively low cost, up to the limitations of thé implementation. — 


ln such a: louical network, each Senisliser shied ae spores: Further, 
cach resource object is a separate site, Instead of, saying. that a process: is executing 
serializer code, however, we say that a site executes code: for some transaction. Local 
variables are associated with. the transaction, ‘and representation components are: 


associated with the site. 


The following description of the: serializer construct: in a message. passing 
model gives an outline of an abstract implementation, for serialivers. At serializer object 
creation, the representation object is initialized, and the serializer site waits for external 
messages to arrive. We describe the serializer events. as follows: 

*enter - An enter event represents the acceptance of an initial request 
message for service at the serializer site. At this acceptance, a unique 
transaction identifier is generated to name the transaction that this event 


starts. ‘The request message ‘identifies’ the ‘operation to exccute, the 
arguments to that operation, and the destination for the reply. A 
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destination is a site name and a. transaction identifier relative to that site. . 


* enqueue - The enqueue event represents the completion of a series of 
actions. First, the transaction identifier, the guarantee, and the 
continuation point are placed in the named queue. Then the guarantees 
at the head of the internal queues are evaluated to determine the next 
transaction to service. If there are ready queues, the serializer site selects 
one of them as the next to process and releases possession. If there are no 
ready queues, the seriatizer site releases possession arid accepts the next 
external message. wha 


* dequeue - After the dequeue event, possession has been regained by the - - 
transaction, the enqueued information has been removed from the queue, 
and the serializer site will continue to‘éxecute code for that transaction at 
the given continuation point. . 


*join - The join event also represents completion of. a series of actions. -_ 
First, the transaction identifier and the continuation point are placed in — 
the named crowd. Then a message is’ sent to the. resource site, 2 
requesting the operation and arguments desired. The message sent to the 
resource site indicates the serializer site as the destination, and also names 
the transaction being processed. Finally, as for the enqueue event, the 
guarantees are examined and possession is released’: -* 


* leave - A leave event represents an acceptance of a reply message from. 
the resource site. Possession is regained by the transaction named in the 
reply.. The information associated. with that: transaction: in. the named 
crowd is. removed from that crowd. The serializer site continues to 
execute code for the transaction at the continuation point. 


* exit - An exit event represents the completion of a series of actions. First, 
a reply message is sent: to the destination given in the enter event. For 
simple serializers, the information in this reply is taken from the reply 
received at the leave event. ‘Then the guarantees are evaluated and 


12. For simplicity, we will assume that the only code that can appear in, the body of a join statement will 
be an invocation of a resource operation. 


-7]- 


FE robs EA RAE tae 


possession released, as for the enqueue and join events. 


The above discussion has presented a very simple view of serializers in a 
distributed system. However, we believe that extensions to this model will not greatly 
affect our description of serializer svents For example, we have assumed that there is 
no more than one request outstanding at a time, so that the site name and transaction 
identifier are sufficient to specify a destination. A natural extension would be to allow 
several. requests to be outstanding. In stich a case, a request number relative to the 


transaction can be included in the destination. 


3.10 Infinite histories revisited 


We noted in our introduction that states can be regarded as equivalence 
classes of histories, a view advocated in [Greif 75] (although Greif discusses partial 
orders of events rather than sequences of events). However, this approach does not 
easily deal with infinite histories, since the state predicates (such as Csize and Qsize) are 
not defined on infinite histories. It would be convenient if we could avoid introducing 
infinite histories, but we have not yet discovered a method that does not require them. 
We introduced infinite histories to model what happens to a serializer object over its 
entire lifetime. Some serializer objects are intended to have unbounded lifetimes, even 


though any physically realizable system must have a finite lifetime. 
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If we reject the use of infinite histories, then we consider the specification 
clauses to be requirements that all finite complete histories must satisfy. Unfortunately, 
this leads to difficulties with showing that the "starving" readers-writers solution could 
not satisfy the guaranteed service specifications, since the counterexamples involve - 
infinite histories where certain events are not required to occur. If the only histories 
considered to be complete are finite histories where after the last event all crowds are 
empty and no queues are ready, then the starving readers-writers solution can be 
proven to guarantee service. The system designer who relied on this proof would be 


unpleasantly surprised to discover that starvation actually occurred under heavy loads. 
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4. Specification language 


One method of specifying a programming language is to provide rules for 
translating programs written in that language ‘aio functions on some mathematical 
domain. This method can also be applied to specification languages. The specification 
language for serializers is composed.of clauses in which certain relations between 
serializer events imply other relations between serializer events. The meaning of 
specification clauses. is given by stating rules for éransforming the clauses into 


specification predicates on histories. 


Serializer code is said to meet its-specifications if every complete history that 
can be fexally generated by the serializer code (according to the partial legality predicate 
discussed in the previous chapter) satisfies all of the eee ification predicates that result 


from the specification clauses for that serializer code. 


It is nof our intention to require that sy specification language have su ficient 
power to define abstract data types. We sare only « concerned . -with soecitving 
concurrency control. We believe that the autlicully of ar AWANE at good ee cation 
methods. dictates that we attack a tractable problem, and integrate the Various 


apne as they are su ficiently well understood. 


In this chapter we discuss the kinds of serializer specifications supported, and 
present the syntax and semantics of the specification: language. Then -we give a full 
specification for the FIFO readers-writers serializer, some: specifications for variations 


on the readers-writers problem, and a partial spectlication for the bounded buffer 
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problem. 


4.1 Kinds of serializer specifications 


The specification language is a notation for requiring a serializer abstraction to 
have certain. properties. These properties are classified as: 
* Exclusion - where one kind of access excludes another, such as readers 
excluding writers in a simple data base. THis kind of specification is 


necessary to prevent concurrent requests from interfering with each 
other. ad _ 


* Priority -. where one transaction is served: preferentially over another. 
This may occur because of the order of enter events, the kind of | 


- transaction, or other reasons or combinations of reasons. 


* Concurrency - where some. accesses are required to be served | 
concurrently. The presence of concurrent processing for requests often .. 
affects the performance of system, and may even affect the correctness. 


* Service - where some (or all) accesses are required to run to completion 

(analogous to requiring termination for sequential programs). 
We make no claim that all interesting synchronization properties fall into the. above 
categories, although many do. We also. make no. claim that all ‘Properties in \ the above 
classes can be expressed in the specification Aonsiae or that the specif ications are ~ 
especially concise in our language. The classes we have chosen are not necessarily 
distinct; some propertics may be considered to be in more than onc class. We are more 
interested in making the specification language usable by: both programmers and 


verification systems than attaining some kind of formal completeness. 
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The specification language has nothing to say about performance, either for 
real time, computation time or storage. Although performance characteristics can be 
inferred from some of our specifications, specifications and proofs of performance are 


beyond the scope of this thesis. 


The simple form of the specification language does not deal with the values 

passed: to or: from serializer operations. This Snphneen has been made to avoid » 
discussing what the exact meaning of ' ‘value" is in the language. The form of the 
specification language i in this ehapier has events, nodes, boolean and integer values, We 
also include limited predicates on ‘these values, and simple arithmetic expressions as 
functions on integers. It is possible to extend the specification language that the user 
sees to include further values and functions, but such extensions involve more of the 
semantics of the complete programming language than we wish to handler in this thesis, 
In the next chapter, certain extensions are mad¢ to the:speci fication language to support 
our verification techniques, but these extensions. are: stil: quite. limited, and do not 


support user-defined values and functions. 
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4.2 Specification language 


The specification language is defined by specifying a mapping from 
specification clauses to unbound specification predicates Each unbound specification 
predicate takes a symbol map and a history into a padienn that sngicales whether the 


specification clause is satisfied for that symbol map and that-history. - 


A symbol map is a function from event symbols to events, and from node 
symbols to nodes. It provides an interpretation in our semantic model of the symbols i in 
the specification clause. A valid symbol map provides a consistent interpretation of 
symbols for a given history, and will be -discussed further later in this chapter. The 
symbol map is an important distinction between the specification language and the 


definition language. 


Each specification clause defines a specification predicate, which maps 
~ histories to boolean valucs: true if the clause is satisfied for that history, and false if it is 
not. The specification predicate for a clause is the -value of the unbound specification 


predicate for that clause taken over every valid symbol map for a given history. 
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4.2.1 Syntax of specification language 


The specification language has a simple syntax. The specifications for 
serializer code are expressed :as a set-of clauses, each clause being expressed as an 
implication. The syntax of the specification language is given informally below, issues 


of parenthesization and precedence being neglected. 


Clause = Clause "D" Clause 
| Ordering | clause 
Ciause "&" Clause. 
Clause "|" Clause 
"~" Clause 
"GX" "(" Event_symbol "," Event_symbol "," Node symbol ")* 
"GX" "(" Event symbot-",” Event. symbol: ge “Event. usy@ol ay ea 
"@” Event_symbol . Pe te 
Expr Order _Op Expr 3. |. ae 


a 


Ordering clause = Event_symbol "<" Evont_symbol 
| Event_symbol "<" Ordering_ clause. 


Order_op = "<" J ">" [ "<" p-tao" Pome yp 


Expr = literal 

Expr "—" Expr 
-Expr "+" Expr 
Expr "*" Expr 
Expr "/" Expr 
"#" Event_symbol 


— me ne ee cent 


An event symbol (Pesan Rane above) is written by writing a -transaction 
symbol followed by the event kind followed by optional information indicating other 
components of the event (with optional digits for further disambiguation). A 
transaction symbol is written by giving the first letter of the operation name (or enough 


letters to be unambiguous) followed by optional digits if more than one transaction for 
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that operation is needed in the clause. Examples of:event ‘symbols for an operation 


whose name starts with "X’ are: 


. *X-enter: This symbol denotes an enter event for transaction X. By 
convention, if there is only one transaction appearing in a specification 
clause for the operation, no digits are necessary in thé transaction snr 
There can be only one enter event for any transaction. . 


* X-join: This symbol denotes a join event for transaction X. For simple 
serializers, this join event is associated with performing the cortesponding 
operation on the resource. Also, for simple: serializers,” We. are Rimnited to 
having one join event for any given transaction. “°“~ ~ 


* X1-exit: This symbol denotes an exit event for.transaction X1. Note the 
use of the digit ‘1’ to indicate-a transaction that is distingt from: X (or X2). 
By convention, we give different transactions: different. digits in 
specification clauses where more than one transaction for an operation is 
mentioned. 


* X2-enqueue(s.q): This symbol denotes a enqueue event for transaction 
X2, where the queue denoted by sq is:used. 


A node symbol (Node_symbol above) is written by giving the first letter(s) of 
the transaction name, followed bya "*", followed by the event kind. For example, the 
enter node for operation X is written as X*-enter. Any further information given is the - 


same as the corresponding event. - 


4.2.2 Semantics of specification language 


We first must describe the domains over which the specification language is 
defined.!? The syntax given above mentions event and node symbols, but does not 
— explicitly demand that the symbols apply to a single serializer. Therefore, we need to 
limit ourselves to nodes and events chosen from some particular serializer, S. We name 
these domains (and representative elements) by: 


~ 


née Ng -- node symbols for S 


é € Es -- event symbols for S 

c€e Cy -- specification clauses for S. - 

x€ Xq -- expressions for S 
Note that we have provided. single character. names for sample elements of the domains. 
We will follov. the leading character convention used. in naming events for naming 
elements of these domains in the later equations, including using trailing digits where 


more than one element is desired. 


The semantic domains are those domains described. in the previaus chapter on 


the semantic model. 


née Ng -- nodes for S 


e\€ Eg -- events for S 


13. Although the denotational method used in this thesis to-define the specification. language owes much 
to work by Scott and Strachey [Scott and Strachey 71, Strachey and Wediworth IE the domains we use 
are simply sets, not lattices. 
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h € Hg -- complete histories for S 
(Hg: Int -> Eg) 


In specifying the meaning of the specification language it is necessary to. 
provide a symbol map that takes node and event symbols into their meanings, We will 


discuss this function at greater length below. 


p € Pc: maps symbols to events or nodes 


The following functions take syntactic values into. semantic values. We or 
that they define the meaning of the syntactic constructs: athe specification language. 
We have avoided parsing and: precedence issties to.-more-clearly present these functions. 
Note that the braces "{ }" are used to bracket'syntactic constructs and distinguish them — 


from the semantic expressions. 


E({e},p) —-- event corresponding to e in map p 
Ni{n},p) -- node corresponding to n in map p 
N: (Ng, Pg) -> Ng | 
C({ic}.p,h) -- validity of specification clause c in map p, history h 
(true ifc is satisfied, false if not) | 
C: (Cy, Po, Hg) -> Bool 
~X({x}.p.h) -- value of expression x in map p, history: h 


(an integer value) 
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x: (Xo, Po, Hg) -> Int 


O({op},p) -- binary predicate corresponding to op 


(Op = {<, >.<, >, =, #}) 


O: Op -> ( (Int, Int) -> Bool ) 


The definition of C({C},p,h) for specification clause C is given below by cases. 


C({cl D c2},p,h) 
C({el < €2},p,h) 
C({cl & c2},p,h) 
C({cl | c2},p,h) 
C({~c},p,h) 
C({GX(cl, e2, n)}.p.h) 
C({GX(el, €2, €)}.p.h) 
C({@e},p.h) 

C({x1 op x2},p,h) 


C({cl},p,h) > C({c2}.p,h) 
Precedes(E({el},p), E({e2}.p), h) 
C({cl}.p.h) & C({c2}:ph) 
C(fel}.p.h) | C{c2}.p.h)- 

~CUichp.h) | 
Excludes_node(E({el},p), E({e2#.p), N({n}.p), h) 
Excludes(E(el }.p), E({e2}.p). E({e}.p), h) 
Occurs(E({el}.p),h) 

O({ op}. pNC({x1}.p.h), C({x2},p.h)) 
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The definition of X({x},p,h) is given below by cases: 
X({x] + x2},p,h) = X({x1},p,h) + X({x2},p,h) 
X({xl-x2},p,h) = X({x1},p,h) - X({x2},p,h) 
X({x1 *x2},p,h) = X({x1},p,h) * X({x2},p,h) 


X({x1 /x2},p,h) = X({x1},p,h) / X({x2},p,h) 
X({literal},p,h) == constant 
X({#e}.p,h) = Rank(h, E({e},p)) 


As a notational convenience, the clause “E] < E2< E3" is equivalent -to 


"El < E2 & E2< E3". Longer clauses of the same form are defined similarly. . 
Some examples of speci fication clauses follow: 


X1-join < X2-join D XI-leave < X2-join 


This clause mentions two transactions, X1 and X2. The intention is 
to specify that having transaction X1 access the resource prohibits X2 
from accessing the resource. 


@X-enter D @X-exit 


This clause is a specification of service for transaction X. The 
occurrence of the X-enter event implies that the X-exit event occurs 
in any complete history. 


©@G-enter & (#G-enter < #P-enter) D @G-exit 


If the enter event for transaction G occurs, and the rank of G-enter is 
not greater than the rank of the enter event for transaction P, then 
the exit event for transaction G must occur. In (slightly) more 
intuitive terms, a transaction for operation G is only required to 
receive service if there are at least as many transactions for operation 
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P as transactions for operation G. 


4.3 The symbol map 


Mapping symbols in the specification clauses to ‘mathematical entities is a 
necessary part of translating specification clauses into functions on histories. It is 
necessary. to map event symbols into events, node symbols: into nodes, and syntactic 


expressions into their value domains. 


The meaning of a specification clause i is taken to be a predicate that, given a 
history, returns true if a history satisfies the specification, and false if it does not. 
Serializer code is said to satisfy a Seciicilipn clause if for every ccriplets history and 
every valid symbol map for that history, the ‘specification: predicate’ defined by that 


clause is true for the history. 
A valid symbol map for serializer S must satisfy the following restrictions: 


* Distinct event symbols must map to distinct cvents, and distinct. node 
symbols. must map to distinct nodes. 


* Event symbols must be consistent with node'symbols. For example, the 
~ event symbol “R-enter" must map to an event that is consistent with the 
node symbol "R*-enter". 


* Fvent and node symbols map to events and nodes that are consistent in 
kind to the symbol kinds. For example, the node symbol "R*-enter" 
must map to a node that is an enter node in the serializer S. 


* Event and node symbols map to events and nodes that-are consistent in 
transactions to the transaction symbols. For example, the event symbols 
"Ri-enter" and “R1-exit" must map to events with the same transaction, 


* Event symbols mentioned in ordering clauses (El < E2) and GX clauses _ 
(GX(El, E2, E)) must map to events that actually occur in‘the history: 
Event symbols mentioned in rank expressions (#E) and occurrence 
clauses (@E) need not occur in the history. 


The last restriction on symbol maps needs further explanation. The 
motivation for introducing it is to. keep specifications of order. separate _ from 
specifications of service. For earns suppose that we are attempting to specify a 
readers-wri iters serializer where writers, are e given priority over other writers solely on the 


basis of ee enter events occurred. To do this, we use the following specification: 


Wl-enter < W2-enter D Wl-exit < W2-exit 
However, if the last restriction does not hold, and we therefore: allow -symbol maps 
where the events corresponding to W1-enter and W2-enter occur in the given order for . 
some history, but either of the events corresponding to WI-exit or W2-exit have not 
occurred, then the specification clause will have a much different meaning. If the event 
occurrence is optional for the symbol map, then a serializer will satisfy the clause if the 
given order holds, and the serializer guarantees service to writers, but #o/ if writers can | 
starve. In this rather surprising way, a priority specification has. implicd a service | 


specification. 
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We believe that keeping the specification of order separate from the 
specification of service simplifies both specifications and proofs. Therefore, we have 
required that a symbol map is valid for some history only.if an event symbol in an 


ordering or GX clause maps to.an event that actually oecurs in the history. 


4.4 Readers-writers specifications | 


Our first examples deal with the readers-writers problem. In this problem, a 
serializer abstraction should allow concurrent access to a simple data base for 
transactions that simply read from the data base, but should not allow transactions that 


write to the data base to overlap, since that could destroy the integrity of the data. 


The same exclusion specifications apply to all versions of the readers-writers 


problem. 


* Readers exclude Writers - A reader ‘accessing the resource prevents a 
writer from accessing the resource. 


R-join < W-join D R-leave < W-join 


* Writers exclude Readers - A writer accessing the resource prevents a- 
reader from accessing the resource. 


W-join < R-join D W-leave < R-join 


* Writers exclude Writers - A writer accessing the resource prevents 
another writer from accessing the resource, 


W1-join < W2-join D W1-leave < W2-join 
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For the FIFO readers-writers serializer shown in Chapter 2,.the priority given 
to a transaction is based on when it arrived with: respect to other transactions, We 
expect strict FIFO ordering. between readers and writers, and between writers and 
writers. Strict priority between readers is not required; because readers may. access the 


resource concurrently. Therefore, we have the following priority specifications: 


* Readers not pre-empted by writers. 
R-enter < W-enter D R-join < W-join 

* Writers not pre-empted by readers. 
W-enter < R-enter D W-join < R-join 

. Writers not pre-empted by other ae 


Wl-enter < W2-enter D W1-join < W2-joi 


The above priority specifications only require: .the order of requests -to be preserved 
from enter events to join events, not from leave events to exit events. If the order of 
service matters after the resource operation is performed, theh we would include the 
following clauses: 

R-enter ¢ W-enter 3D R-exit < W-exit 

W-enter ¢ R-enter D W-exit < R-exit 


Wl-enter < W2-enter D W1-exit < W2-exit 


In the readers-writers case, we specify concurrency for readers by the 
following specification: 


GX(R1-enter, R2-enter, W*-enter) & R2-enter < R1-leave 
D R2-join < R1-leave 


This clause is interpreted as requiring that for any two readers, R1 and R2, that enter 
the resource without a writer entering the resource between R1 and R2, if R2 enters 
before Ri has completed accessing the resource, ‘then- R2: will begin. to access the 


resource before R1 completes its access. - 


We cannot require that two readers are actually concurrently executing 
resource operations, Gace actual coneanirency fay dlepciid oi the: scheduling policy 
followed on a multi-processed machine, or on the relative speeds of two niecessors if 
the requests are executed by separate machines, oro further concurrency limitations 
imposed by the resource. The kind of specification that we must settle for is to require 
that both requests are sent to the resource (in join cvents) before-eithier reply from the | 
resource is acknowledged ‘(in leave events). A-concurrency-specification only requires. 


the opportunity for concurrent execution, unhindered by the serializer. 


The specifications of service for readers and writers are simply that for every 
enter event there should be a corresponding exit event, and that: this should hold for 
both readers and writers. The specification clauses are: 


@R-enter D @R-exit 
@W-enter D @W-exit 


45 Variations of the readers-writers problem 


Other versions of the readers-writers problem exist [Courtois, Heymans 
and Parnas 71, Greif 75]. Aside from differences based on the’ programming language 
used, the versions di ffer mostly because of the kinds of priority they Bive to readers or 


writers and the presence or absence of starvation. 


The simplest priority specifications often conflict with other specifications. | 
For example, suppose that the person specifying :the serializet wants to give. writers. 
priority. The intention might be: "whenever a writer enters a serializer before a reader 
-has been serviced, the writer should be serviced before the reader.” This specification 


can be written as: 
W-enter < R-join D W-join < R-join . 


Further, we can write serializer code that will realize this specification. Unfortunately, 


if writers arrive at the serializer at.a sufficiently. high. rate:with respect to the length of 


-. time the resource$write takes, readers can. be indefinitely prohibited: from. joining the 


resource. This would confliet. with the guaranteed service requirement given above, 


since there can be no specification that prohibits writers from arriving at the resource, - 


A more reasonable specification of writer's priority is to require "if a reader 
and a writer enter the serializer while a particular other -writer-is being serviced, then the 


writer will be serviced before the reader." This specification can be written as: 
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(W1-join < W2-enter < W1-leave & W1-join < R-enter < W1-leave) 

> WI1-join < R-join 
This specification does not conflict with our service specifications. Regardless of the 
number of writers that enter while resource$write is being performed for W1, the 
readers that entered in that period feed not be delayed for any writers arriving after 


that period. 


The guaranteed concurrency specificatiens may also. differ from serializer to 
serializer. We may wish to require for the readers-priority serializer.that all.ceaders that 
enter while a writer is accessing the resource will be allowed, to concurrently. access the 


resource. This specification can be written as: 


(W-join < R1-enter < W-leave & W-join ¢ R2- -enter ¢ W- Hae) 
~D (R2-join < Ri-leave & R1-join < R2- leave} 


This clause ‘requires that for every pair of readers, Rl and R2, centering the serialize 


while a writer ts accessing the resource, that both readers begin to access ae resource 


yep EB: fh Ae oe ee 


before either reply is acknowledged. 
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4.6 Bounded Buffer Specifications 


| The bounded buffer problem!4 is based on operating system vO buffering, 
We assume that there is a producer of information, and a consumer of information. 
The producer Sears put requests to the system to pass the information to the consumer, 
and the consumer issues gef requests to obtain the items of information from the 
system. In order to allow both producer and consumer to operate in parallel, the system 
provides a bounded buffer of length N to store items of information that the producer 
has delivered to the system before the consumer has requested them: The producer can 


proceed as long as it is no more than N items ahead of the consumer. 


We have somewhat generalized the problem by allowing minlupte consumer 
and producer processes for each bounded buffer. If the producer consists of several 
processes, then each process can proceed until it performs a ‘pa request where the 
request is made on a full buffer. Similarly, each consumer process can proceed until it 


performs a gel request on an empty buffer, 

We assume that the resource acts as a bounded sequence of information . 
items, !> where the sequence cannot be more than N items long.. The put operation 
‘appends an item tothe head of the sequence, while gef operation removes an item from: 


the tail of the sequence. 


_ 14. A monitor approach to this problem appears in [Howard 76]. Serializer code for this problem 
appears in the appendix to this thesis, and is discussed in our conclusions. 

15. Although this kind of sequence is also known as a queue, we avoid the use of the term to distinguish 
between the queues used by the serializer code for scheduling, and the queue used for the data. 
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The following specifications are conditional service specifications for the 


bounded buffer problem. 
((#G-enter + N> #P-enter) & @P-enter) D @P-exit 


((#P-enter > #G-enter) & @G-enter) > @G-exit 

The G-enter event is the initial event of some get transaction, and the P-enter event is 
the initial event of some put transaction. We require that the P transaction complete if 
there have been enough G transactions to use the data, or if there is sufficient room in 
the buffer to store the data. If the G-enter event is the i-th event using the G*-enter 

node, and the P-enter event is the j-th event using the P*-enter node, then P must 
complete if j < i+.N. Similarly, we require that a G transaction complete if there have. 
been enough P transactions started to supply.the data, Fherefore,.G wilt complete if 


i<j. 


Note that the above specifications need to use. @G-enter and .@P-enter 
- because we only automatically require events appearing in ordering specifications to 
occur in the histories. This choice was made based on ‘Thenconventetice of writing 
certain examples. To illustrate, if: the use of #G-enter required @G-enter, then the 


specification of service for P transactions above would have. been. written as two elauses: 
(~@G-enter & (# P-enter < N)) D @P-exit 


(#G-enter + N> #P-enter) D @P-exit © 
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Another specification of the bounded buffer problem is that the order of get 
requests and put requests cannot be interchanged, cither in forwarding the request to 
the resource, or in returning the result. These specifications are similar to the FIFO 


readers-writers priority specifications, 
Gl-enter < G2-enter > (G1-join < G2-join & Gl-exit < G2-exit) 
Pl-enter < P2-enter > (P1-join ¢ P2-join & Pl-exit < P2-exit) 
We have chosen the exclusion specifications to be quite simple: accessing the 


resource is exclusive. The exclusion specifications are expressed by the following four 


clauses. 

Gl-join < G2-join D Gl-leave < G2-join 

G-join ¢ P-join > G-leave ¢ P-join 

P1-join < P2-join D Pl-leave < P2-join. 

P-join < G-join D P-leave < G-join 

We have said that the serializer operations should, us fir as practical, have the 

same effect as the resource operations. In the bounded buffer problem, the serializer 
operations have the same effect as the cluster operations provided that the cluster - 
operations return normally. In executing a pus operation for the serializer, if there is no 
room in the bounded buffer for the item, the operation pauses until there is reom. In 
executing a gef operation, the operation will not proceed until an item is available. For 


‘the operations of the resource, however, an exception is signalled if there is no room in 
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the buffer when executing a put operation, or if no item is present when executing a get 
operation. The signals of the resource operations have become the non-terminations of 
the serializer operations. This raises the question of how well we have separated 


concurrency control from data access. We will discuss this question in the conclusions. 


We have presented the bounded buffer. problem: as: an illustration of the 
specification language and as an example of a serializer that is slightly beyond simple 
serializers. We will return to this example to illustrate how we can perform extensions 


in the program proving domain as well. 
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5. Verification Rules 


| In previous chapters we have used a definition language | based on first-order 
predicate calculus to give the meaning of both the serializer construct and the serializer 


specification language. In theory, we need aahine else to verify that a sefialines mects 


its specifications, In practice, a certain amount of intermediate work is necessary. 


| We have chosen to build'a verifi ier that operates i in a restricted domain. The 
_ verifier applies rules that-are specific to this domain to data it has describing a serializer 
and specifications for that serializer. Fhis chapter states and proves those files: Our 
choice of rules is based on their utility in verifying a number of variations of the. 
readers-writers problem (these examples are presented in the next chapter). No claims 
will be made for their completeness. Other classes of problems would most likely lead 
to different sets of rules, although we would expect most such rule sets. to have 


substantial intersections with the set we have chosen. 


_In this chapter, we first argue that proofs can be reasonably performed in an 
extended specification language. We then state and prove a number of verifi cation: 


rules expressed in the extended specification language. These rules are used in * 


‘program that performs automatic verification of serializers, to be discussed in: the nekt 
chapter. A method for proving service specifications is then presented that ts partially 
based on these rules, and its correctness argued. To illustrate the use of the verification 
rules, an example of a rule-based proof is given. Finally, certain weaknesses of our: 


methods are examined. 
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5.1 Proving in the specification language 


In proving that a serializer meets its specifications we start with the text for a 
serializer and a number of specification ened In proving that serializer code meets its 
specifications we need to state intermediate propositions about the serializer code and 
the specifications. To do so we needa ianpiiage to state the prepositions and rules of 


inference that can be used for the language. 


One candidate for such a language is the dialect of predicate calculus that we 
used to define serializer semantics. If we used this definition language as the proof 
language of the verification program, then we would be faced- with the following tasks: 
translating specifications into their meanings, reasoning in the definition language 
about propositions expressed in the definition language, and translating the results into 
some humanly readable form. The translation from specification language into 
definition language is relatively easy: we have already described it in the previous 
chapter. The translation from definition language into specification language is more 


difficult, 


We considered it to be preferable to carry out our reasoning, as far as 
practical, in the specification language. It ts the language that the user is most likely to 
understand. Further, we find that most of the inference rules are casicr to state and 


manipulate in the specification language than in the definition language. 
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The verification program can be simply viewed as a data base. about the 
serializer code, a set of algorithms that are used to examine and modify the data base, 
and a set of specification clauses to prove about the serializer. The data base can be 
expressed as a set of node graphs representing the Serialer operations, and a set of 
assertions about the serializer, expressed as specification clauses. The algorithms are 
largely rule-driven, where a rule is used to infer a specification clause from known 
clauses... The rules we present in this chapter are treated as axioms by the verification 


program; this chapter states.and proves the rules. 


5.2 Extensions to the specification language 


As it stands, the specification language presented in the previous chapter is 
oriented towards describing external properties of serializers. It has No constructs for 
describing the internal structure of a serializer. The rules we define in this chapter 
require a means for describing the node graphs for the Spencers and relating Been 


to the node graphs. Therefore, we propose extensions to the specification language. 
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5.2.1 New symbols and clauses 


The extensions to the specification language pase no special. problems. They 
extend the domain of discourse for the language to include symbols that can represent 
any event (or node), and to include components of events and nades: For the sake of 


simplicity, we will not formally define these extensions, although we could do so. 


* seneral event’symbols - E,E1;E2,... are event symbols: that can be — 
__ associated with any serializer event through the symbol map. 


* gencral node symbols - N, Nl, N2,... are node.symbols that can be 
associated with any serializer node | in the node Braphs. 

* extended expressions - E.trans, E.node, E.kind are added as. expressions 
that represent the components of events, N. kind, N.next, N. expr, and 
N.mob expressions are also added. An extension to the domain of 
expression values to’ include: events;. :teansaction:: identifiers, nodes, 
syntactic expressions, and node ands is Laila we ats: sede 
literals for nodekinds. = ‘ Gs 


*GX (Guarantee Exclusion) specification ‘extensions - 
~ GX(Node, Node, Node) is added as ‘a syntactic form: The. function — 
rede Ee eentare te is used as its mene: ow) N2, Dee OF DICE 


transaction is executing Selwecue Nl and N2 (inclusive). 


* PX: (Possession | Exclusion) — specification’ clauses - We use 
ENO: baad clauses to Teel Lara Soaartae vas N2) 


syeet 


some other jiinsietion is executing belweeii Nl ei N2 inlsive. We 
will define the meaning of PX clauses below, ps 
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5.2.2 Marked and unmarked events 


In defining the verification rulesiin: this chapter we have occasionally found it 
necessary to write ordering clauses where one or more of the events appearing in those 


clause are not required to occur, To achieve this, we introduce the notation 


!E 
to indicate a marked event wise in the specification clause. We then modify the 
definition of a valid symbol map to require that all unmarked event symbols appearing 
in ordering clauses and GX clauses must map to events that occur'in the complete 
history for which the map is defined. In all other respects, a marked event symbol is the 


same as an unmarked event symbol. 


' The alternative to introducing the !E nctation is to-not require-a valid symbol 
map for some history to take event symbols appearing in ordering and GX clauses into 


events that must occur in n the histo ea, We would then explicitly Feu the use of @E 


to require event occurrence in clauses where such. occurrence. was. important, We have 
previously rejected such: an- approach, because it leads to surprising implications for 
some specifications. We believe that it is still the right ‘choice: we prefer to have some 
additional complication inthe language for defining, the verification rules so we can 


retain some simplicity in the specification language at the user level. 


We note here that the Precedes predicate used to give the nicaning of ordering 
clauses is well-defined even when the events do not occur in the histories. Note that the 


clause 
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'El < 1E2 
can only be true for some history if both events denoted occur in that history. This can 


be stated as the-clause: 


1El < !E2 D> @El & @E2 
Also note that if an ordering clause mentioning two events that need. not occur i is S false, 
it could be due to either the opposite order helding, the two events being the same, ¢ or 


non-occurrence of either event, as is expressed by: 


~('El < !E2) > (!E2 < !El)| ~@E1 | ~@E2 


5.3 Some simple inference rules 


In this section we present proofs for several inferenée rules stated in the 
specification language. These rules are presented as specification clauses where one 
sub-clause implies another. Note that the rules ee actually nile generators: free 
variables are permitted to appear to denote: nodes:and events.. The free node symbols 
are chosen from the set {N, NI, N2,...}. and the free event syinbols ire chosen from the 


set {E, El, FQ, ...}. 
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5.3.1 Transaction order 


Events belonging to the same transaction must occur in the order prescribed 
by the node graph for that transaction. We can write this restriction as an inference 


rule: 


Transaction order rule: 
El.node.next = E2.nede & El.trans = E2.trans 
DEI < E2 


Proof: For every valid symbol map p and complete history -h, since El and E2 are 
mentioned in an ordering clause, p maps El and E2 to events that occur in h. 
Therefore, there must be events el and e2- (with indices | and J), such that the 
above rule is equivalent to: 

(el = Nth(h, I) = E(Q{E]}.p) 
&ez = Nth(h, J) = E({E2} p) 
& Same_trans{{, J, h) 
& el.node.next = e2.node ) 
DIi<§ 
‘Since an enter node can not be the next component of any node, e2.kind # enter. 
“Wherefore, by the definition. of Legal_transaction_step, there must be some index 
K € Index_set(h) such that - — - 
(K<J 
& Nth(h, K).node.next = e2.node 
& Nth(h, K).trans = e2.trans ) 


Further, K = I by Legal_transaction_step, which proves that I < J. 
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5.3.2 Transitivity 
The event ordering is transitive. This can be expressed bythe following rule: 


Transitivity rule: 
(El < E2 & E2< E3) 9 El < E3 


Proof: By the definitions iven in chapteg.3, the above specification clause is defined to 
be equivalent to: 
( Precedes(E({E1}.p), E({E2},p), h) . 
& Precedes{E({E2},p), E({E3}.p), hb) 
> Precedes(E({ El}, p). E({E3}.p), h):: goa 
where p is any valid symbol map for the obbititeie history’ ‘h. ‘By the definition of a 
valid symbol map, there must be three distinct events (el, e2, e3) that occur in h, 
which implies that there are three distinct noes We 4, Ce eah sa oe above rule 
is equivalent'to: ae 
(el = Nth(h, f) = E(fE1}.p) - 
& 2. = Nthth, J) = EQE2},p). 
&3= = Nth(h, K) = E({E3},p) 
& Precedes(el, e2, h) & Precedes(e2, ¢3, h)) 
> Precedes(el, 3, h) 
By the definition of Precedes and the existence of the indices 1 and J, 
Precedes(el, ¢2, h) is equivalent to 1<J. ‘The other Precedes expressions’ have 
similar simplifications, ‘Therefore, the specification clause is equivalent to. 
(IKI & IKK) DKK) Sn, Ae 
which is true by the axioms of integer ordering. ‘Therefore, the specification clatise 
is a true statement. | | 
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5.3.3 PX clauses 


A PX clause is used to specify Possession exclusion. .The meaning of a PX 


clause is given by: 


C({PX4a)},p.h) = PX_def(M({n1},p), M({n2},p), h) 


PX_def{N1, N2, H) =. 
vIJ,K € Index_se(H): 
if (Nth(H, !).node = NY a Nen(H, J).node = = 
& Same_trans(H, |, J) 
then Excludes(Nth(H, dD, Nih(H, J).. Nth(H, K) 


The clause PX(N1, N2) specifies that a. transaction executing nodes N1 and. 
_N2 has possession (of the serializer containing NI and N2).after-executing Ni and up to 
the completion of executing N2, and that N1. next = = N2. Bia that while a transaction 
has possession no events from another transaction may occur, “There are two rules used 


to imply PX clauses: 


PX from gain rule: 
(NIi.next = N2 
& ( N1.kind = enter 
| N1.kind = dequeue 
[| N1.kind = leave) ) 
> PX(NI1, N2) 
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PX from PX rule: 
( PX(N1, N2) 
& N2.next = N3 
& N2.kind # join 
& N2.kind # enqueue ) 
> PX(N2, N3) 


Proof: By contradiction. For the first rule, suppose that the precondition implies 
~PX(N2, N3). By the definition ofa. valid’ ‘syiibol ‘hap, there miust be three 
distinct events (e1, e2, e3) that occut in ‘any"C omnplete: history fh, which implies that 


there are three distinct indices (I, J, K) such thats, 
el = Nth(h, 1) & e2 = Nth(h, )) &e¥ = = Nh K 
& el.node = N({N1},p) & e2.node SCN, py 
&el.trans = e2.trans & el.node.next = e2.node 
& (el. kind = enter I el. kind = dequeue | el ind’ = Fea) 
& ~ ~Excludeste 2, €3, ih), 


A ger doue (o 


ar re 


graphs for the seiializes Sccritions) Further, Bechlise agian Hi is true (by 
the definition of Busy and Gains), e2 is the only event’ that is a Tegal step. 
Therefore, no events can occur between el and” ‘e2," “which contradicts 
~Excludes(el, e2, c3,h). Therefore, the PX from ‘ain rife i iS true. A similar Hie 
holds for the PX from PX tule. ome REN Deane, a) Ske 


The PX clauses are useful as intermediate steps that. imply event ordering. 


The following rule is used to imply an event ordering from a PX rule and other 


preconditions. 
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Event before PX rule: 
( PX(N1, N2) & E< E2 & El.trans = E2.trans 
& El.node = N1 & E2.node = N2) 
DEX El 


Proof: The above clause is equivalent to the following (for every valid symbol map p 
and complete history h): . 


( PX_def(W({N1}.p), NQZN2},p),-h) 
. & Precedes(E({ E}.p), EQ E2},p), h). 
& E({E1},p).trans = E({ F2}.p). trans 
& E({E1},p).node = N({NI}.p) 
& E({E2},p).nodé =.NM{N2}.p).) .- 
> Precedes(E({E},p), E(Q(ER}.p). bh) 


Because E, El, and_ E2 are mentioned in ordering clauses, there must be three 


distinct events (el, e2, e) that occur in h, which implies that there are three distinct 
‘indices (L J, K) such that, by the definition of PX def. . 
(= Nth(h, = = E({ El}p) | 
& e2 = Nth(h, N= ‘EK E2}.p) 
&e= Nih(h, K) = ‘E({E}. P) 
—& Precedes(e, e2, h) 
& Excludes(el, c2, ¢, h)) . 
which implies Precedes(c, e1, h), which implies that. the rule is true. 
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The other PX rule is quite similar, and can be stated as: 


Event after PX rule: 
-(PX(N1, N2) & E1< E& El.trans = E2.trans. 
& El.node = NI & E2.node = N2) 
DE2Q<E 


Proof: Similar to proof for Event before PX. 


5.3.4. GRE clauses 


The GRE G uarantee Requires Empty) clause i is an antecmediateé sep used to 


infer Gx (G Harantted sr le clauses, The definition oF the GRE clause i is: 


C({GRE(N1, N2)},p,h) = GRE _deftNCENT}, p), N(EN2}. E h) 


where 


GRE_def(nl, n2, h) = 
-WIJ,K € Index_set(h): 
if ( Neh(h, node = n2 
& Nth(h, J).node = n2.match 
&I<K<J 
& Same_trans(h, 1, J) ) 
then ~Eval( Head(h, K), n1.expr ) 


The intuitive meaning of GRE(N1, N2) is that the queue or crowd denoted by N2.mob 


must be empty in order for the expression N1.cxpr to be true. 
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There are two rules that can be used to infer GRE clauses: 


GRE from empty rule: 
Nl.expr = Empty_expr(N2.mob) 
> GRE(NI1, N2) 


GRE from expression rule: 
( Nl.expr = And_expr(Empty_expr(N2.mob), G) 
| Nl.expr = And_expr(G, Empty_expr(N2.mob)) ) 
> GRE(N1, N2) 


Note that we have had to add some ad hoc extensions to the specification language. G. 
denotes a. boolean-valued- xpEssion: Empty_ expr(N. MOD) denotes either. 
queueSempty(N. mob) — or. crowdSempty(N. mob), J = appropriate, and 


_ And_expr(G1, G2) denotes the expression: that is the conjunction of the two guarantees, 


Proof: By definition of GRE_def and the Eval function. For the first rule, suppose-that 
the guarantce is crowd$empty(C). Then for any history that contains a join event 
for that crowd but does not contain the corresponding Jeaxé event the guarantee 
will evaluate to false, which proves the rule. Similar ‘reasoning holds far the first 
rule if the guarantee is sea A sie taal aioe for the GRE from 
expression rule. aH 
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5.3.5 Using GX clauses 


GX clauses are used to indicate where events are excluded because of 
guarantees being: false. For example, if a puaranitee, for a queue is ‘crowdSempty(C), 
where C is a crowd, then a dequeue event with that guarantee Is prohibited from 
occurring between a join and a leave event for any transaction for that‘ crowd. The 
following rule is used to infer GX clauses. 

GX from GRE rule? 
(Nt.match = N2 & N2 #N 
-& (N1.kind = join | NI.kind = enqueue) 
&N.kind = dequeue 
& GRE(N.expr, N2.mob) ) 
2 GX(N1, N2, N) 
The clause GRE(N1, N2) used above is true ii the expression Nl.expr requires the . 


queue or crowd N2.mob to be empty for the expression to: be true. 


Proof: By contradiction. Suppose that GX(N1,N2,N). is not true, yet the 
preconditions are met, By the definition, of a. valid symbol map, there must be 
three distinct events (el, e2, e) that occur in any complete histor y h, which implies 
that there are three distinct indices (I, J, K) such that: 
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(el = Nth(h, I) = E({N1},p) 
& e2 = Nth(h, J) = E({N2}.p) 
.&e = Nthth, K) = E({N}p) 
& el.node.match = e2.node | 
& (el.kind = join | el.kind = See 
& e.kind = dequeue | 
- & Precedes(el, e, h).& Precedes{e,e2,h)) . ; 
Further, from the GRE clause we know that the guarantee for event e must be false 
for any prefix of h that contains el but does not contain e2. Since e occurs after el, 
we have a contradiction (due to Legal_dequeue), since e is a dequeue event that. 
occurs when its guarantee is false. Therefore, the GX from GRE mule is true. 


GX clauses are a useful intermediate step that can be used to infer event 


orderings. 


Event before GX rule: 
(GX(N1, N2, N) & E< E2 & El.trans = E2,trans 
- & Enode = N & El.node = N1 & E2.node = N2) 
DEEL 


~ Proof: Because E, El, and E2 are mentioned in ordering clauses, for any valid symbol 


map p and complete history h, there must be events seh €2, c) Gctistring at distinct 
indices (I, J, K) such that: : 
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- (el = Nth(h, 1) = E({E1},p) 
& e2 = Nthh, J) = E({E2},p) 
& e.= Nth(h, K) = E({E}.p) 

_ &enode = N({N},p) 

— &el.node = N({N1},p) 

& e2.node = N({N2},p) 
& Precedes(e, e2,h) . 
& Same_trans(h, I, J) 
& Node_excludes_node(el.node, e2. seas e.node, »). 


By the definition of Node_excludes_node we can-infer: = 
Excludes(el, e2, c) & Precedes(e, e2, h) & e + el 


which implies that Precedes(e, el, h), which. oe that the clause E< El. and 
therefore the tule, is true. 


As with the PX clause, there is a symmetrie rule to. Event before GX. 
Event after GX rule: 
(GX(N1, N2, N) & El< E& El:trans = E2.trans.. 


& E.node = N & El.node = NI & E2.node = N2) 
DE2<E 


Proof: Similar to proof for Event before GX. 
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5.3.6 FIFO queues 


Serializer queues are served strictly first-in-first-out. The following rule is 


used to infer event orders from the use of FIFO queues in sertalizers. - 


Event from FIFO rule: 
(El < E2 & El.kind = enqueue & E2.kind = emuueue:* 
& El.node.mob = E2.node.mob 
& E3.trans = El.trans & F4.trans = F2.trans 
& E3.node = El.node.next & EA.node. = “E2.node.next ) 
> !E3< E4 


Proof: By contradiction. First, suppose that E3 occurs (we are not required to do so by 
the clause). As in the above proofs, El, E2 and E4 are unmarked events mentioned 
in ordering clauses; so they must.occur. There must be four events (e], e2, e3, e4) 
with distinct indices:(1, J, K, 1.) such that: ; 

(el = Nth(h, 1) = E({E1},p) 

& e2 = Nthh, J) = E({E2},p) 

& e3 = Nth(h, K) = E({£3},p) 

& e4 = Nth(h, L) = E({E4}.p) 

& Precedes(el, e2, h) 

& el.kind = enqueue & e2.kind = enqueue 

& Same_trans(1, K, h) & Same_trans(J, Lh) 

& c3.node = el.node.next & e4.node = c2.node.next ) 

We need to prove that Precedes(e3,c4,h), which we do by assuming | 
Precedes(e4, e3,h), and finding a contradiction. By the definition of 
Legal_transaction_step we know that Precedes(el, c3, h) and Precedes(e2, e4, h). 
Let hl be the largest prefix of h that does not contain e4. We will show the — 
contradiction by considering the predicate Legal_step(h’, e4, S), where S is the set 
of node graphs for the serializer. 
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_ Since e4.kind = dequeue, Legal_step(hl,e4,S) requires that 
Legal_dequeue(h]1, e4) be true, which requires that Eval be true for the guarantee, 
and that Head_enqueue(hl, J) be true. Head_enqueue(hl, J) is only true if every. 
other transaction with an enqueue event for, the: queue:e4.node.mob that occurred 
in hl prior to e4 has a corresponding dequeue event:that has occusred in hl. 
However, we know that e3 has not occurred in hl. by: our assumption of 
Precedes(e4, e3, h). Therefore, either DIeedeR 2; e4, h), or e3 does not occur. 


The proof that e3 occurs is simple. We know that of occurs in h, since it is 
denoted by an unmarked event mentioned in an ordering clause. Therefore, when 
e4 occurs, €3 must have occurred in the history. hl by the definition of 


Legal_dequeue. 


5.4. Evaluation of guarantees 


In further rules we will need to express the evaluation of guarantees. The 
clause EVT(G, E) is used to specify that expression G. always evaluates to true 
immediately before event F. ‘The clause EVF(G, E) is used to specify that expression G 
always evaluates to false immediately before event E. In translating from specification | 
- language to definition language we will assume that, if the event denoted by E occurs at 
index I in history h, then 

C({EVT(G, E)}.p,h) = Eval(Head(h, 1-1), {G}) 
C({EVF(G, E)},p,h) = ~Fval(Head(h, I-1), {G}) 
When the event denoted by E does not occur, the EVT and EVF clauses are undefined. 


We are careful to.only use these clauses.in- contexts where such.an event does. occur. 
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The following rule can be used to infer’ EVF clauses: 


EVF rule: 
( (El. kind = enqueue | El.kind = join) 
- & El.node.next = E2node - 
& El.trans = E2.trans 
& El < E< E2) 
ps Na are, E) 


Proof: Suppose that M is a queue. By the defi nition of Legal_ transaction, “step, there 
can never-be more dequeue events than enqueue ‘events for any transaction. 
Therefore, by the definition of Csize, the queue is empty (Csize(M) = = 0) only if all 


transactions. have the same number of enqueue events as dequeue events - 


immediately preceding E. However, the transaction El.trans has an enqueue event . 
(El) that has occurred without the matching dequeue event (F2).: RSIS the 
qucue must not be empty. A similar proof holds.if M is:a crowd. . 


The following rule can be used to infer EV'F-clauses: 


EVT rule: 
(Ww ELE2: 
if (EL.trans = E2.trans & El.node.mob = M- 
& El.node.match = E2.node ) 
then E < EL} !E2< E) 
D> EVI(Empty_expr(M), E) 


Proof: First, we note that within the quantification the events E and E] are required to 
| occur, yet the event E2 is not required to occur, since it is marked. ‘The condition | 
that we are expressing with the quaatified clause is that for every pair of events. 
denoted by El and F2 the event denoted by E either occurs before (or is-the same 
as) El, or occurs after E2. Note that if EL< E is true, then 'E2 <¢ EF is false if E2 
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does not occur. In order for Empty_expr(M) to be false. when evaluated 
immediately before E there must be some transaction that is ia M immediately 
before E, which means that the enqueue (or joi) event (call -itE1) occurs before E, 
but the dequeue (or leave) event (call it E2) does not occur before E. We can 
express this requirement as 


E1< E<!E2 . 
which is prohibited by the precondition 
E<EIL|!E2<E 


and therefore the clauses always evaluates to true immediately before E. 


The above clause uses internal quantification over alt events, which is another 
extension to the specification. language. It is difficult tot use ‘the above nule as it is ina 
verification program due to the internal quantification. The set of all events is infinite, 
and cannot be enumerated. We can . prove that the quantification clause i is satisfied by 
contradiction: proving that there can not exist a éranssetion with events El and E2 (as 
given above) where the clause within the quantification is not satisfied. This method 


will be further discussed in the next chapter. 


The following ‘rules can be used for guarantees that are conjunctions or 
disjunctions, These rules are sufficiently simple that we will omit the proofs. 
EVT from conjunction rule: 
(G = And_expr(Gl, G2) . 


& EVI(GI, E) & EVT(G2, E)) 
2 EVT(G, FE) 
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EVT from disjunction rule: 
(G = Or_expr(G1, G2) 
& (EVT(G1, E)| EVT(G2, BE))) - 
3 EVI(G, £) 


EVF from conjunction rule: 
(G = And_expr(Gl, G2) 
& (EVF(G1, E) | EVF(G2, E))) 
> EVF(G, E) 


EVF from disjunction rule: 
(G = Or_expr(G1, G2) 
& EVF(GI, E) & EVF(G2, E)) ~ 
> EVF(G, E) . 


We have used G, Gl, and G2 to denote guarantees, and And_expr and Or_expr to 


Geno conjunctions and mslunetons: of guarantees. 


5.5 Priority of dequeue over enter and leave 


ail there are queues with true puaranices vided posscssion is released, a 


» dequeue event for one of those queues will occur ell an enter or Feave: event. 


Suppose we know that an-enqueue event El occurs before an external gaining. 
event E. To show that E must occur after the dequeue event: E2 corresponding to El, we 
must know that the guarantee for El is true immediately prior to E, and oe there can 
be no transaction with a false guarantee that ts in the queue ahead of the transaction for 


El when E occurs. 
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Event from ready queue rule: 
((E.kind: = enter | E.kind = leave) 
& El.node.next = E2 & El.trans = E2.trans 
& El.kind = enqueue 
& EVT(El.expr, E) & EL< E 
& ¥ E3,E4: 
if ( E3.kind = enqueue & E3. mob = = El. mob 
& E3.trans = FAtrans 
& E3.node.next = E4.node 
- & EXCEL): oo 
then EVT(E3. expr, By 7 bere < E y 
DIE2<E | 


Proof: We will outline a proof by contradiction. Assume that the gaining event E 

_ precedes the dequeue event B2, such that. El <E < F2. The quantification over E3 

and F4 isa precondition that requires every transaction ‘that has entered the queue 

before El.trans to either have a true ‘pudraiitee’ (imhiiediatety’ béfore £) or to have 

Jeft the queue before: the gaining event: E. ‘Therefore, there can:be: no transaction 
with a false guarantee in the queue ; ahead of El. trans. However, the gaining event 

E cannot occur while there is a queue with a true guarantee, which is true for” 

El.mob. This is a contradiction, so we can infer that if £2 occurs, it must occur 

before E. By similar reasoning,: E2 must,occur,. since. if.it dogs. net occur; there will. 

be a ready queue when E occurs (E must occur, since it is an unmarked event). | 


Note that the above rule was expressed as implying 'F2< E, which not only 


implics an ordering between events, but also implies that the event denoted by E2 


occurs, since any event the precedes an event that occurs must also occur. 
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The above rule is admittedly long and complex. We can shed same more light 


on the reasoning behind its form by considering some examples. 


* Suppose that there are events E3 and E4 such that E3’< El, and EA does © 
not occur (using E, El, E2, E3, and F4 as in the above rule).: Then the © 
precondition expressed by the quantification must be false, which means - 
that we cannot infer. E2 < E. “Fhis should:seem, reasanable, since by the 
FIFO queue rule we know that E4 must precede E2 if E2 occurs, which 
implies that E2 does not occur. 


* Suppose that there are events E3 and E4 such that EVF(E3.expr, E) and 
F3< El. Then it is possible for E3.trans:toibe at.the +ead-of the queue 
when E is ready to occur, which would imply that E < E4, or that EA. did, 
not occur at all. 


The reader may note that we have only considered a single queue in the above - 
rule. It may be imagined that all of the precondiions were met for two queues, yet one ~~ 
queue was arbitrarily. chosen to. proceed, whi then made the head guarantee of the 
other queue false, which then allowed the gaining event E to occur. Such a situation is 
éovers by our rule, since. we do- not specify evaluation. of the guarantee at any” 
particular time, but rather anmediately. before the event E in any context. Intervening 
dequeue events from other queues are unimportant, since they will only postpone the |. 


occurrence of F, not change the precondition EVT(ELexpr, E). 


5.6: A method for proving service 


A service specification typically states that for every complete history and 
valid symbol map, the occurrence of an enter event for some trarisaction implies the 
occurrence of the exit event for that transaction. In proving this, we typically need to 
prove that the occurrence of any event (exit events excluded) in a transaction implies 
the occurrence of the. next event in the transaction. Another way to state that the 
occurrence of one.event implies the occurrence of another is to say that every complete 


history that contains the first event contains the second. 


For most events in a transaction, if an event occurs, the successor event in that 
transaction must occur. For simple serializers, the occurrence of an event that gains 
possession implies the occurrence of a corresponding event that releases possession. 
Further, we have assumed that accesses to the resource terminate, so the occurrence of a 
join event implies the occurrence of the corresponding leave event. There are only two 
kinds of events where the occurrence of an event does not imply the occurrence of the 
successor: exit events, heise they have no successors: and_enqueue events, because 
they might never have true guarantees whenever possession is released, or because there 


might always be another queue ready whenever possession is released. 


The method we propose for proving that an enqueue event requires a dequeue 
event is to first suppose that the dequeue event docs not occur, then prove a 
contradiction: that a complete finite history cxists where there is a ready queue at the 


end of the history. 
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Suppose that we want to prove @E1 D @E2, where E1 and:E2 belong to the 
same transaction, and El precedes E2 if both events occur (which can be written as 
@E! & @E2 D 'E1< 1E2). We need to show for every enqueue event E3 with 
corresponding dequeue event FA that if E3. trans = = EL. trans then the occurrence of E3 


implies the occurrence of FA (@E3 ) @EA), 


' If an enqueue event occurs for some queue and the dequeue event does not 
occur, then we say that its queue is blocked. Ifa queue is blocked, then we can infer the . 


‘following: 


* If every join event for some crowd requires a ‘preceding dequeue event — 
from a blocked queue, then the crowd will eventually become empty. . 
This is true because when the queue is blocked, theré can be no further _ 
join events, and every join event requires that a leave event occur... 


_* If every enqueue event for some queue'Q requires that a dequeue event — 
for a blocked queue B must. occur. (because the enqueue event. must ~ 
follow some other dequeue event ‘that is waiting for B to empty), then Q — 
will eventually become either blocked or empty. Since.the-cnqueve event. 
for Q will not occur, then no new transactions:will be added to Q, which — 
implies that only dequeue events for'Q can possibly-decur. Eventually... 

- either Q is empty or a transaction with a false guarantee is at the head of ~ 


Q. 


* If every occurrence of an enqueue event for some queue implies the 

occurrence of a corresponding dequeue event, and the queue will 
eventually become cithér blocked of empty, then! thequene will | 
eventually become empty. a. 


By saying that a condition “eventually becomes” true, we mean that for every complete 


history there isa event where the condition is true at every event after that event. 
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The method is now clear: to prove the contradiction, we assume that the 
dequeue event (E) does not occur, that certain queues and ‘crowds will pecaihe empty, 
and that certain queues will become either empty or blocked. If these additional 
assertions are sufficient to prove that the guarantee for E is true, and that. there is no 
other dequeue event with a false guarantee that is blocking E, then’ we have found a 


contradiction, and actually proved that E must occur. 


- We will not present rules for proving service. The number of supporting rules 
is relatively high, and the additional material would not introduce any new concepts 


The method of proving service will be further explained in the next chapter. 


5.7. Rule-based proving of FIFO priority specification 


In this section we present a proof based on successive applications of the rules 
we have presented in this chapter. As presented in the previous chapter, the FIFO 
readers-writers problem has the following (partial) priority specification: 

Rl-enter < Wl-enter D R1-exit < Wl-exit 
A rule-based proof of the above clause takes two stages: derivation of intermediate 
clauses (stich as PX, GRE, and GX clauses); and use of the rules that imply event 
orders. Note that the first stage need only be performed once for any particular 


serializer, while the second stage is usually different for every specification clause. 
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In the first stage, we examine the node graphs:and. use the PX from gain rule 
to derive the following PX clauses, which indicate possession exclusion: . 
PX(R*-enter, R*-enqueue(x.xq)) 
PX(R*-dequeue(x.xq), R*-join(x.1c)) 
PX(R*-leave(x.rc), R*-exit) 
PX(W*-enter, W*-enqueue(x.xq)) 


PX(W*-dequeue(x.xq), W*-join(x.wc)) 
PX(W*-leave(x.wc), W*-exit) 


We then examine the node graphs and use the GRE from empty vale and the GRE 
from expression rule to derive the following GRE clauses: 
GRE(R*-dequeue, W*-join) 


GRE(W*-dequeue, R*-join) 
GRE(W*-dequeue, W*-join) 


Using the GRE clauses and the GX from GRE rule, we derive the following GX 
clauses: 
GX(W*-join, W*-leave, R*-dequeue) 


GX(R*-join, R*-leave, W*-dequeue) 
GX(W*-join, W*-leave, W*-dequeue) 


In the second stage of the proof, we prove the implication by assuming the 
precondition, and deriving the conscquence.. We. use the Transaction order rule to. 


derive: 
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(Rl-enter < Rl-enqueue < R1-dequeue 
< R1-join < Ri-feave < R1-exit) 


& 


(W1-enter < W1-enqueue < W1-dequeue 
< W1-join < W1-leave < W1-exit) 


_ Then we perform the following inferences, using the indicated rules: 


Event order 

Rl-enter < W1-enter 
Rl-enqueue < W1-enter-. 
Rl-enqueue < W1-enqueue 
R1-dequeue < W1-dequeue 
Rl-join < W1-dequeue 

R l-leave < W1-dequeue 

R l-exit < W1-dequeue 
Rl-exit < W1-exit 


Rule applied 
Assumed - 
Event after PX 
Transitivity 
Event from FIFO 
Event after PX 
Event after GX 
Event after PX 


Transitivity 


5.8 Comments on the verification rules 


While the intent of defining inference-rules in the specification language is to 
simplify verification, one unfortunate side-effect has been to add numerous clauses to 
the specification language. These additions have made the specification language far 
closer to our definition language than we would like. As we add more extensions we 
begin to lose the simplicity that proofs in the specification language have over proofs in 


the definition language. Despite these misgivings, the rules do appear to work at a 


higher level than could be obtained from the definition language. 
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We have added a means for vOGNE the fequncement that every event 


if® ciph 


mentioned in the ordering clauses must map. (via Abe. symbol, map) to an event that 


occurs in the complete history on which the map is based. There is no inherent reason 


zs 


ef 


why this ability should not be extended to the u eel Se, although we have chosen not to do 


are 


so. This feature. is only rarely used, and continues to. have potentially sirptising 


“ Misa « DHE 


interpretations, as evidenced by the Event from ready queue rule, ‘where the occurrence 


HEGG Hos PMP ba 


of an event was proved without resorting to the @E notation. 


atei 
Deriee A 
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6. Automatic Serializer Prover 


The previous chapter presented verification rules that were defined in an 
extended specification language. This chapter describes a program that makes use of 
those rules. While limited to dealing with: simple serializers and: ‘specification clauses 
that do not mention the rank of an event, many of the principles used are applicable to 
more general serializers. The program, called ASP Caitomate pela Prover), has 


been tested on a number of versions of the readers: -writers problem. 


In this chapter, we discuss the structure of ASP, ‘fi rst ‘by giving an overview, 
then by’ detailing some of the: algorithms vised: The. resutlts for the readers-writers 
examples are given, and we discuss how ASP could be extended to accommodate 


various extensions to simple serializers. 


6.1 Overview of ASP 


The input to ASP is a description of each operation ofa serializer and the 
specification clauses for the serializer, We use. ASP interactively to prove that the 
specification clauses are satisfied, or to examine why they are not. The execution of 


ASP has the following phases: 


* Initialization: This phase builds representations of the node graphs for 
the serializer operations given ‘the text. for the’ operations. i: In the 


16. In the actual program, the text must undergo an initial translation by hand in order to be processed. 
This allowed us to concentrate our efforts on verification rather than parsing. 
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remainder of this chapter, we will make no distinction between the. node 
graph representations used by the program and the node graphs used in 
the semantic model. 


* Static. analysis: This phase examines. the node. graphs to determine 
possession exclusion, represented by the PX clauses mentioned in the 
previous chapter, and guarantee excltision; represented by GX ‘clauses. 
Note that we also make no distinction between the, Specification: clause 
representations used by the program ‘and the actiial clauses. . | 


* Verification: In this hake we attempt to prove seach specification clause 
given. Typically, a- specification ‘claus¢ is given as an ‘implication . 
consisting of a precondition clause and a consequent clause. Proving such 
a Clause involves assuming the precondition and using | the inference rules 
described in the previous chapter to derive the consequent clause. When 
a consequent clause is derived, further.rules may be: applied to derive new 
clauses. 


The node graphs, specification clauses, and other data are kept.in a structure 


called the data base, which is composed of the following parts: 


* Node graphs: There is.a node graph for cach operation of the serializer. 
Fach node has. a structure as described in Chapter 3. Data structures 
representing expressions (as in N.expr), queues: and crowds (as in 
N.mob), and kinds (as in N.kind) are referred to by the node graphs. 


*'Transaction stack: There is a stack of transactions that represent the 
‘transactions mentioned in the specification clauses. © Fach transaction 
symbol in a specification clause has a corresponding, transaction in this 
stack. Further transactions may be added to this stack due to attempted 
proof by contradiction, as mentioned in the previous: chapter. When such: 
an attempt succeeds or fails, such a transaction is removed from the stack. 


* Assertion stack: There is a stack of specification clauses that have been 
asserted and the rules used to assert the clauses. The asserted clauses are 
those that have been assumed to be true or have been added by 
application of the inference rules ‘tothe clauses.in the assertion stack. 
This stack provides a record of which rules led to particular event 
piers as well as an efficient mechanism for TOME assertions. 


* Event stack: There is a stack of the events that exist «(although do not 
necessarily occur) for the transactions in the transaction stack. This stack 
is closely coupled to the stack of known transactions, since each event in. 
this stack must have a known transaction. Whenever a transaction is 
added to the transaction stack, ari'event for évery node’ that the 
transaction may.execute is added to the event stack. When a transaction 
is removed from the transaction stack, all’ events for that trarisaction are | 

removed from the event stack. 


- *fvent order matrix: There is an extensible square’ matrix used to — 
represent event orders. There is a row and a column for. each event, with 
the entries indicating the ordering between the events. “The row and - 
column index for a particular event are identical, and the index for an 
event in this matrix corresponds to the index in the event stack for the 
event. The matrix is extended or retracted (in both dimensigns).:as the. - 
event stack is extended or retracted. 


6.2 Static analysis phase 


The static analysis phase inserts PX and GX clauses into the data base 
according to the node structure of ‘the operations. It is performed in advance of 
examining the specification clauses. The purpose of the static analysis phase is to 
perform steps that can be done once for a given serializer, and avoid performing these 


steps for every clause we wish to prove. 
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The PX (Possession Exclusion) clauses are generated by examining the node 
graph to determine when a transaction is in possession of the serializer. For simple 


serializers only the PX from gain rule is needed. 


The GX (Guarantee Exclusion) clauses are generated by ecauninihe the 
guarantees on enqueue statements during the initial pass over the serializer. They are 
generated according to the GX from GRE rule, which depends on the GRE from 
empty rule and the GRE from expression rule. As tong as the guarantees only involves 
testing the emptiness of crowds or queues, or “conjunctions, (G1 & G2) of tests for 
emptiness, GX clauses can be generated for the guarantees during static analysis. 
Guarantees that are disjunctions ore) or. negations (~G) do not generate GX 


clause during static analysis. 


6.3 Verification phase 


A specification clause is usually written as PDQ, where P and Q are 
specification clauses that do not use implication clauses. Verifying that PDQ is 
satisfied involves assuming that the precondition clause P is true, and showing that the 
consequent clause Q is therefore true. Note that the clause P is assumed to be true fora 
particular choice. of complete history and valid symbol map. The verification 


methodology allows us to prove: 


v p.h: (PDQ) 


The assumption and proof should not be viewed as: 


(Vv p,h: P) >-(v p,h: Q) 


- When a clause not previously in the assertion stack is asserted, we say that it is 
inserted into the data base. When a clause. is inserted, ASP checks eta rules to 
determine whether they are immediately applicable. These rules are called insertion 
rules, and are: Transitivity, Event before PX, Event after PX, Event before GX, Event 
after GX, and Event from FIFQ. If any are applicable, we assert the event ane: clauses 
they imply. This, in turn, may lead to the assertion of further clauses, and so.on. This — 


process is complete when no further insertion rules are applicable. . 


In serine an event érdetings we ceed t to ae computer represtiitations of 
events. In order to have event representations, we need transaction and node i 
representations. The initialization phase built the nodes. The transactions and events 
are built by examining the specification clause to determine which transactions < are 
mentioned in the clause. These transactions, and their associated events, are added t to | 


the data base. 


For each transaction that. is added duc to. being explicitly. named in the 
specification clause, the Transaction order rule is used to determine the order of the 
events that belong to the transaction. This leads to the insertion of. event order claliscs, : 
but does not inncdiitoly lead to the application of any rules-vther than the transaction 
order rule and the transitivity rule, since there is no known initial. ordering between 


events from different transactions. 
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To prove an implication, we assert the precondition‘and ‘attempt to derive the 
result. The precondition for a specification clause is asserted by performing operations 
on the data base to assume the various parts of the clausé. For example, one 
component of the specification clause may be an ‘event ordering, El <E2. This clause is 
asserted by calling the add_order operation’ of the data base. If this clause was not 


previously asserted, the insertion rules are applied by this operation. 


6.4 Evaluation of guarantees and anonymous transactions 


In several places in ASP it is neexseaty to evaluate a Baranice, to determine if 
a queue is ready. The EVT and EVF clauses mentioned in the previous chapter are 
used to indicate the evaluation of guarantees. EVT G, Bi is true for some history that 
contains E if the guarantee G evaluates to true in the largest prefix of the history not 
containing E. EVAG, Ei is true if G evaluates to alse in tha prefix. For example, if 
the event E. occurs between conieencnding enquene ‘and ‘dequeue events for some 


transaction, as in: 


X-enqueue(Q) < E< X-dequeue(Q) 


then we can assert the cues 


EVT(queue$empty(Q), E) 


In some cases, it is‘not sufficient to simply use the EVT and EVF rules 
presented in the previous chapter. Consider the following concurrency specification for 


the FIFO readers-writers serializer: 
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Rl-enter < R2-enter < Rl-leave & GX(R1-enter, R2-enter, W*-enter) 
> R2-join < R1-leave 


In proving this specification, we need to prove 


-EVT({crowd$empty(x.wc)}, R1-leave) 


The insertion rules are sufficient to prove that the writers crowd (x.wc) is empty when 
the readers crowd (x.rc) is not empty. However, the rules we have presented do not 
immediately allow us to soneludle that the EVT "clause above i is true, since we must 


prove the clause for all writers. 


A more general method of proof is available to us, based on proof by 
contradiction. If we assume that a writer is in the writers crowd, and that leads toa 
contradiction, then the writers crowd must be empty. ‘To be éxhaustive in choosing the 


writer, we have two cases: 


1: The writer can be a writer that already exists in the transaction stack. To 
assume that some writer W is in the writers crowd: when R1-leave occurs, 
we assert: | _ 

W-join’< R l-leave < W-leave 


and apply the insertion rules as necessary. A contradiction occurs if this . 
leads to F< E being asserted for any event E (cyclic event orders are 
prohibited by Legal_transaction_step).. [f-no. contradiction occurs, then 
we cannot prove the EVT clause. If all writer transactions in the 
transaction stack cannot be in the writers crowd, it is necessary to apply 
the second case. 


2: If no writer in the transaction stack can be assumed to be in the writers 
crowd, it is still possible that there is some other writer that can be in the 
crowd. Therefore, we invent an anonymous transaction and place it in the 
transaction stack, and assume that‘the new writer is in the crowd, as in the 
first case. If assuming that the anonymous transaction in in the crowd 
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leads to a contradiction, then we can assume that. the writers crowd is 
empty at R1-leave, and therefore the EVT clause is true. 


The above method is easily generalized to proving any queue or ‘crowd empty. . 


6.5 Checking for ready queues 


The Event from’ ready queue rule is difficult to apply, sirice there is nested 
quantification. We start by examining the data base for dequeue events where the 
guarantees are true immediately preceding enter or leave events. Consider some’ 
transaction X, where X-dequeue has a true guarantee immediately before some enter or 
leaye event, which we will call E. If E is known to orcur after, X-enqueue, then the only 
way that E can occur before X-dequeue is for there to be a transaction in the same 
queue, ahead of X, with a false guarantee. If such a transaction exists, we say that it 


blocks X-dequeue. 

If no known transaction can block ‘X-deqtietre,’ it’ may still be possible that 
some other transaction not mentioned in the specification: clause can: block -X-dequeue. 
Therefore, we create an anonymous transaction’ Z for ah opération (provided that that 
transaction can have an enqueue event for the:same queue as X-dequeuc), and assert. 
that | | | 

Z-enqueue < X-enqueue ¢ Z-dequeue 
where X-enqueue and 7-crnqucue occur for: the same. queue. If the guarantee for 


7-dequeue is true immediately before E, then Z cannot blogk, X. Further,, if asserting 
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that Z-dequeue occurs after E causes a conflict, then there can be no such transaction Z. 
If there is no Z, for any operation of the serializer, that can block X, then X-dequeue 


must occur before E. 


6.6 Proving by cases 


One potential drawback of using the insertion rules is that some relatively 
simple proofs will be unachievable because there are not enough assertions. In 
particular, if enter events E] and E2 are known to occur, yet the order of El and E2 is 
unknown, we may be able to prove a clause if we assume either El < E2 or E2 < El, yet 
be unable to prove the clause if no order is assumed. ASP can perform some of these 
proofs by cases: where the order of El and E2 is unknown, first assume El < E2 and 
sedeni the proof, then retract the assumption of El <2, assume E2< El, and 
perform the proof. If the desired result is obtained in both cases, the proof is valid, 


provided that El and F2 are known to occur. 


The concurrency specification clause given for the FIFO serializer was overly 
restrictive, since it specified that 
Rl-enter < R2-enter < R1-leave 
and the result (R2-join < Rl-leave) can be shown to be true even if R2-enter ¢ R 1-enter. 


The following clause is a stronger version of the concurrency specification that requires 


proof by cases: 


-GX(R1-enter, R2-enter, W*-enter) & R2-enter < RT-leave 
> R2-join < R1-leave 


Note that the GX clause does not specify that Rl-enter < R2-enter, although the GX i. 
clause is trivially satisfied if R2-enter < Rl-enter. Initially the precondition is asserted. 
Then ASP first assumes Rl-enter < R2-enter, proves the consequent clause,,Pettacts.the 
assumption, then assumes R2-enter < R1-enter, and proves the consequent clause. That 
R1-enter and R2-enter occur can be shown i in two ways: ‘they are mentioned in a GX 
clause, and events subsequent to them (by Legal. ‘transaction; -step) are mentioned i in.an 


ordering clause. 


6.7 Proving guaranteed service 


In many serializers we would like.to prove that every transaction feceives. 
. service, i.e., for every enter event there is an. exit event. The following is a typical — 


service specification clause: 


- @T-enter D @T-exit 
Proving guaranteed service for a transaction is performed by proving that cach dequeue - 
event that the transaction can execute is guaranteed to occur, since we have assumed for 
simple serializers that all other kinds of events will occur in complete historics given 


their predecessors. 


Proving that a dequeue cvent occurs is largely done by contradiction: We: 
assume that the dequeue event does not occur, which implies that its queue ts not 


empty, and that any crowds that require dequeue events from that queue will empty. 
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This is generally enough to show that the guarantee for the dequeue event is true. The 


dequeue event must occur if no other queue is ready. 


In this method, evaluating the guarantees must take place immediately prior 
to some event, since that is the basis of our evaluation mechanism. But there may be no 
actual event occurring, especially if no further enter events occur. Therefore, we invent 
a fictitious event with certain properties. We assume that some "quiet point" event QP 
occurs, such that the event QP gains possession of the serializer only when no queues 
are ready, and QP occurs late enough such that every crowd or queue that must empty 
has emptied. If the guarantee for the dequeue event in question is true at QP, and there 
can be no blocking of the dequeue event, then the dequeue event must precede QP, 
provided that QP does occur. We can guarantee that QP does occur if every other 
queue is not ready at QP. At this point we have proved that QP does occur, and the 
dequeue event precedes QP, but we assumed that the dequeue event does not occur. 


This is the contradiction that proves that the dequeue event does occur. 
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For extended serializers, it is possible for a request kind to have guaranteed _ 
service, yet the quiet-point method is too weak. To illustrate, suppose a serializer has _ 
the following operation: 

op = proc (x; cvt)- 
if queueSempty(x.q) 
' then % O-enqi . 
enqueue x.q until crowdSempty(x. c) 
else % O-eng2 
enqueue x.q until crowdSempty(x. be & -~croudSompty( x. cc). 
_ end. 
join x.c % O-joint 
end 
join x.cc % 0-join2 
end - 
end op : 


For simplicity, we will suppose that op is the only:operation.of the serializer that can get. 
sole possession (uses cvt). The QP: event. will not: occur:until x.c is empty. and x.cc is 
empty. However, at QP the.guarantee for O-enq2:is false. Therefore, it seems possible 
for QP to occur before O-eng2, so guaranteed service cannot be proven. 

One way to prove guaranteed 8 service for the above serializer is sto o split the 
proof into two cases dependent on the test | gcisenslen gi in the if aitement if the 
test was true, the QP method will work. If the test is false just before O-enq2-occurs, 
then there must be at least one other transaction, call it Ol, that is in x.q when the 
O-eng2 occurs. But then there are two more cases, based on whether. or not 
crowd$empty(x.c). Vf x.c is empty, then the guarantecs for x.g must be true, and O-deq2 
must occur before Ol-leave, which must occur before QP, which guarantees service. If 
x.cc IS not empty, then there is yet another transaction, call it O2, such that x.c will be 
empty at O2-join2, which implies that the guaranices for xg will be true before 


O2-Ieave2, which must precede QP. Although this analysis by case would be expensive, 
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it would be possible to add to ASP. 


The reader might object that the above example is: quite contrived, and we 
would agree. We have discovered no- convincing realistic: ‘examples that require: more 
than the simple QP method, even when extensions td seriblizits: are ‘eoncidered: For 


this reason, ASP supports galy the simple QP method.. 


6.8 A sample verification 


This section presents a sample verification performed by ASP. Figure 4 figure 
shows the results produced by using ASP to verify a priority clause for the FIFO 
readers-writers serializer presented in Chapter 2. Input from the user is indicated by 
underlining, The user starts the session by typing in the fanie of the ‘serializer that 
should be used. That name is interpreted as a file name, wheré'the fite shduld contain a 
description of the setiafizer 1 in the format  requited a ASP. “Then ‘the user types the - 


itis to be verified. 


The response from ASP indicates whether. the clause could be proved, and 
shows the assertion stack after the insertion rules have been applied (the first clause 
printed is the most recently: asserted clause), This: information is usually sufficient to — 
cnumerate the steps of the proof, or to. demonstrate why the clause could not be proved. 
While we will not describe them in this thesis, additional. aids are present for more. 


detailed inspection of the steps that ASP uses to prove clauses. 
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Figure 4, A sample verification by ASP 


Name of serializer: FIFO 
1.012 seconds to setup. 


Specification clause: | i 
Proved Implies(Ri-enter < Wi-enter, 
:  Ri-exit < Wi-exit), . 

base[39: 
Ri-exit < Wi-dequeue- xq: “Possession exclusion, 
Ri-leave-rc < Wi-dequeue-xq: Guarantee exclusion, 
Ri-join-rc < Wi-dequeue-xq: Possession exclusion, 
Ri-dequeue-xq < Wi-dequeue-xq: FIFO queues, 
R1-enqueue-xq < Wi-enter: Possession exclusion, 
Ri-enter < Wi-enter: Assumed, 
TR: Wi-enter: From clause, 
TR: Ri-enter: From clause] 

1.376 seconds. : 


Note in Figure 4 that not all of the mules are shown, The default used is to 
omit showing the clauses asserted in the static analysis phase, and use ¢ of the Transaction 
order and Transitivity rules. The notation “base[ 39: m appearing. in the middle of the | 
figure indicates that the assertion stack has 39 members. At the end of the figure the 
amount of processor time needed for the proof is given. This figure includes the 
processor time necessary to- purse the expression, apply the ‘verification rules, and to 
print the results. The notation "TR: wi-enter: From clause” is used to indicate that: 
the transaction W1 was added to the’ transaction’ stuck’since’ the ‘transactian was 
- mentioned in the specification clause (for unifortrity inthe program this is treated as an 


assertion). 


6.9 Performance results 


In this section we present a number of verifications performed by ASP on 
variation of the readers-writers problem. Each test is given as a specification clause to 
be verified (or not verified) for different readers-writers serilizers, Figure 5 presents 
these specifications, most of which have been mentioned in previous “chapters as 


specifications of different properties for the readers-writers problem. 


Figure 5. Readers-writers tests for ASP 


Wpri: Writer's priority 
Ri-join < Wi-enter < R2-enter < W2-enter < Ri-leave 
2 W2-join < R2-join 


(NWPRI): Modified Writer's priority 
Wi-enter < RI-enter < W2-enter < Wi-leave 
2 w2join < rijoin 


Rpri: Reader's priority 
Wi-enter < W2-enter < Ri-enter < Wi-join 
2 R1i-join < W2-join 


(NRPRI): Modified Reader's priority 
Ri-enter < Wi-enter < R2-enter < Ri-leave 
2 r2join < wijoin 
|] &: Concurrency for Readers 
GX(Ri-enter, R2-enter, W*-enter) & R2-enter < Ri-leave 
2 R2-join < R1i-leave 


XexY: X busy excludes Y busy 
X-join < Y-join D X-leave < Y-leave 


XpoY: X not by-passed by Y 
: X-enter < Y-enter D Xexit < Yexit 


GS(X): Guaranteed service for X_ 
@X-enter D @Xexit 
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An abbreviation for each specification is given prior to each clause. The Wpri a 
and Rpri clauses specify writer's and reader's priority properties. The (NWPRI) and 
(NRPRI) Saiises specify alternate versions of these properties to be proved for the 
NWPRI and NRPRI serializers (to be shown below). The XexY clause actually denotes 
three clauses: RexW, WexR, and WlexW2, where appropriate substitutions apply. The 


XpoY clause also denotes three clauses, with the same substitutions. — 
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Figure 6 presents the code, in abbreviated form, for each of the seven 
readers-writers serializers tested. The create operations and headers have been omitted, 
as is the trailing code after any join. The use of crowd$empty: and: queue$empty is 
implicit where empty is used. There is one FIFO serializer, two readers priority 
serializers (RPRI&NRPRI), _ three writers” ~ pelotity” serializers (WPRI]I, ° 
WPRI2 & NWPRI), and one serializer, that allows. starvation (STARVE). Note that the 
priority specifications for RPRI and NRPRI differ, and that there are also two distinct 


writers priority specifications. 


The various serializers above were developed. at Mifferent times, In particular, 
NRPRI and NWPRI were written: after: ASP had besome: relabavely: reliable. We | 
originally attempted to. prove the Rpri speci ACaion clause for the NRPRI serializer. 
The attempt ‘vas made much more" ‘difficult * wes ae preconeepeee ‘tdue to a faulty. 
informal proof) that the dase could be proved: ‘After much effort to determine the 
cause of the fault in the program, we finally noticed that the proeray was correct: not 
only was the clause not satisfied, but the intermediate Sere foligwed by ‘ASP provided a 
counterexample. It was this example more than any other that convinced us of the 


worth of automatic verification aids. | 


The modified writers priority specification came about as a lest of the 
speculation that NWPRI. satisfied a bpuonty clause that was symmeti to ) NWPRI, since 
the serializers were (roughly) symmetric. The unmodifi bd tiles priority clase is also 


satisfied by the NWPRI serializer. 


ee 


Figure 6. Code for test serializers 


Name. 


FIFO 


RPRI 


’ WPRII 


WPRI2 


STARVE 


NRPRI | 


NWPRI 


Oper Code 
enqueue | 
enqueue 

R enQueue 

W enqueue 
enqueue 

R enqueue 
enqueue 

W enqueue 

R enqueue 

-: enqueue 

W enqueue 

R enquaue 

Ww _ enqueue 

Rs enqueue . 

W enqueue 
enqueue » 

R enqueue 
enqueue 

Ww ‘enqueue 


| MALLY. . 
empty(we )&empty(rc); join 


until 
until 


uatil 
until 


Junatti 


until 
until 
until 


until 


untit 


until 


until 


until 
until 


untat 


until 
until 
until 


empty(wc);, join. rc. 
empty(we )&empty(rc); join 


empty(wc); join re. . 
empty(rq) 
empty(we )&empty(rc}; join 


empty(wq) |empty(rc) 
empty(we); join rc 
empty(rc)&empty(wc); join 
eantytre) 

empty(we )Sempty(rq}; join 


ampty(we); join.rc 


empty(we); join rc 
empty(wc )&empty( rc) 
ompty(wo)Sempty('rc); join 


emety(ic). 


we 


wc 


te - 
empty(rc)&empty(we) ; join , 


wc 


we 


empty(wc); join:re 


empty(wc )&empty(rc); join 
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we 


The results in Figure 7 were obtained on 23 August 1979. The times given are 


Figure 7. CPU times for ASP tests 


Name Time WexR WexW RexW RpoW WpoR WpoW Wpri Rpri {| R GS(R) GS(W) 


FIFO 21 #T T T T T T F oF .T t.. 7. 
RPRI 35 T T T T ? T F T T T T 
WPRIL 47. TT T ? T T T F ? T T 
WPRI2 67° T FT °F PCP Op gorge T 
STARVE 24. T Tot | ee ee ery eee | ? ? 
NRPRI 36 T T T T ? T F T T T T 
NWPRI 30 T T T PF 467 Toot ts at 


Time is given in CPU seconds. 
T indicates a Proved clause, F indicates | a | disproved clause. 


CPU. ions for running all of the tests shown.!7 The test cases are explained in detail 
at the bottom of. the figure. Each column after the. ‘Time Solana represents a different 
test, given. by a speciicoudn: clause. A T represents, a proven specification: clause. AnF 
Tep resents a speci ification clause proven to be always filse: A ? represents a specification 
that could not proven true or false. In disc seiulizera represented i the table: below 
there were no cases where the program was not capable enough to prove or disprove a 
clause that was always true or false. In: general, if the proeriny ean not prove or 
disprove a real it is either due to a clatse that i is: imme for some histories and. false for 


others, or it is due to a weakness in the verification methodology, and ASP will be 


17. These tests were performed on 23 August 1979, using a Deesystem-20001. ASP occupies about 100K 
36-bit words of memory, of which about 68K words are,duc to the CLU support system> No appreciable 
paging activity took place. 
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unable to distinguish the two. 


6.10 Summary of methods used 


This section provides a concise summary of the methods we have used in ASP. 
In this summary we follow the order of steps used in ASP, rather thar: prea 


following the order of presentation for this chapter. 


* Static analysis is performed ‘once for any given serializer code to 
determine initial clauses that are: derivable solely’ from” the ‘node graphs 
for the serializer operations. The’ remainder of the stéps are performed 
for ay given specification clause. 

* Representations are introduced’ for the transactions _ mentioned | in, the 
specification clause. 

* For any specification clause of the font P- 2: Q, the Hane Pi is ee 
and we attenipt to derive Q through use of the itiertion refés, Which are 
the rules Transitivity,-Event before PX, Event after PX, Event before GX, 
Event after GX, and Event from FIFO. If these tules are not'sufficient to 
prove Q, further. methods must be used. - 


* The Event from ready queue rule, which reflects the priority of service 
given. to. internal. qucues over the. external. queue,, is Applied, where 
feasible. This is known as "checking for ready queues.’ "This rule may 
result in the invention of anonymous trartsactions, which are essential to 
the proof by contradiction that the preconditions for the rule are met. 
Anonynious transactions may also be ‘used’ in the’ EVE ‘file: which is 
subsidiary to the checking for ready queues. 


* When the clause Q is still not proved, and the order of certain enter 
events is not known, although the events are knows te occur, ASP tries all 
permutations of stich events. ff °Q’can “be? proven for every such 
permutation, then P D Q has been proved. 
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* Proof of guaranteed service is performed by assuming that a transaction is 
blocked in a queue, then proving that a ready queue must result at some 
"quiet point.” Although this method is limited, it can be proven to be 
correct, and works for a variety of cases. 
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7. Interaction of Serializers 


In previous chapters, we introduced the seridlizer construct, presented a 
specification language for serializers, and demonstrated some verification techniques. 
Our discussion has been limited to single instances of simple serializers. Yet if we are to. 


- reach our objective of modularity, we must examine how serializers interact. 


In this chapter we present an application of serializers that incorporates the 
use of multiple serializers.° We are especially concerned that serializer use can be 
nested, so that the techniques for modular decomposition of programs in a single 


process domain can be applied to a multiple process domain. 


The example we have chosen is the use of serializers to control concurrent - 
access to a simple file system. For this example we will assume that objects in primary 
memory can be shared by several processes running on a single processor. This choice 
is made to keep the example simple enough to be tractable, since presenting a 


distributed version of a filing system involves issues well beyond the scope of this thesis. 


We start this chapter with a presentation of the simple file system, including a 
discussion of the abstractions involved. We then show two of the scrializers used to 
control concurrent access to the file system, and show how the specifications are similar 
to the readers priority variant of the readers-writers problem. Further sections concern 
methods for introducing serializers for abstractions that were written for single process 


environments, and a discussion of higher-level transactions. 
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7.1 The file system 


The structure of the file system is based on directories and files. A directory is. 
a map from names (expressed. by strings) to entries, which are either files or directories. 
If directory Y is named in directory X, then Y is a child directory of. X,.and X is the 
parent directory of Y. There is a single directory, called the soot directory, that has no 
parent directory. Files and child directories may -be added to. or deleted from 
directories. A simple provision is made for iterating over the names of a directory. It is 
possible to get.the number of entries in a directory, and to. determine which. directory (if 
any) is the parent of a given directory. For most operations, A directory. must be. open 
for the user to perform those operations. Opening a directory is accomplished by the 


directory$open_dir operation. ‘The directory structure is acyclic. 


A file is an array of pages, where a page is some fixed length unit of data. 
Pages on primary memory may be read from or written to any existing page in a file. 
Pages may be added to or removed from the end of a file. A file may be named by only 
one directory. It is possible to get the number of pages in a file, and to determine which 
directory names the file. As with-directories, a-file must be open for the uscr to perform 
most operations. A file opened by directory$open_private can only be accessed by a 
single process, while a file opened by directory$open _ public can be accessed by any 
number of processes (although a practical system might impose some reasonable timit). 


A file is closed by the fileSclose operation. — 


- 152 - 


At this point, some additional explanation of the open and close operations is 
in order, First, we have made the open operations work on directories, since directories 
are the logical means for initially accessing ftles ‘and child directories. We have made 
the close operation work only on the object that the open provides, which prevents 
users from closing a file (or directory) except when they ‘have acquired that file or 
directory object through an open ‘operation. Second; we have two different kinds of - 
open operation on files: open_public, for simultaneous decéss:among several processes 
(or users), and open_private, for sole access. We éan associate an open count with each 
file or directory object. ‘This count is increased for‘every Open operation, and-decreased _ 
by every close operation: The directory$open: private operation will only succeed when: 
the count is zero, and upon successful completion, prevents any increase in the count. 
The directory$open_dir operation opens a child directory such that multiple processes 


can access it concurrently. 


In presenting the file system example we will concentrate on showing the | 
interface of the file and directory data abstractions and the code: for the file and 
directory serializers. It will not be necessary to show the implementation of the file and. 


directory dita abstractions, although we will discuss some of the details as necessary. - 


Figures 8 and 9 present the interface specifications for the directory and file 
clusters. As a first approximation, these are the same interface specifications that are 
used for the corresponding directory and file serializers. “Bach operation interface 
names the operation, the types of the arguments, the oes of the reenince Shiels and 


the types of exceptions that can be signalled. We include some comments that indicate 


2153 


Figure 8. File interface 


A file may be described as an array of. pages that exists on remote 
storage. It can be randomly accessed, and can , be. extended or retracted 
at one end. An open file can only be obtained througt use “of a directory: 
open_private or open_public operation. No operations. can be performed on 
a closed file except for is_open. . The following | ‘tile operations are 
available to the user (others will be discussed later’ in the chapter):. 


get_parent (file) returns (directory) signals (file closed) — 
Get parent directory of file if file is open, otherwise signal 
file closed. 


get_name (file) returns (string) signals (file_closed) 
Get name of file as a string if file is open, otherwise signal 
file_closed. 


get_size (file)-returns (int) signals (file closed) 
Get number of pages in the file if it is open, otherwise signal 
file_closed. 


is_open (file) returns (boo1) 
Return true if file is open, false if it is not. 


read_page (file, int, page) signals (file_closed, bounds) 
Copy a page of information from the given location in the file i.to 
the given page in primary memory, provided that the file is open. 
Signal bounds if the location is invalid (less than 0, greater than 
or equal to the size). Signal file_closed if the file is closed. 


write_page (file, int, page) signals (file_closed, bounds) 
Copy a page of information from the given page in primary memory to 
the given location in the file. Signal bounds if the location is 
invalid, file_closed if the file is closed. 


close (file) signals (file closed) 
Close file if it is open, otherwise signal file_closed. 


add_page (file, page) signals (file_closed, no_room) 
Add a page to end of file, signalling if the file is closed or there 
is insufficient room to complete. 


rem_ page (file) signals (file closed, empty) 


Remove a page from the end of the file, signalling if the file is 
closed or the file has no pages. 
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For concurrent access, there are the following classes of operations: 


The 


Info: can 
Read: can 
Write: can 
Sole: can 


operations in 


overlap with any but sole access 
overlap with read or info access 
overlap with info access 

not overlap 


each class are: 


Info: get_parent, get_name, get_size, is_open 
Read: read page 

Write: write _page 

Sole: close, add page, rem_page 


Figure 9. Directory interface 


A. directory functions | ‘as a syaboT table of entries, where. each | entry is 
either a file or andther directory. Entries can be | creatad,. deleted or 
opened using the directory. The totais operations are Bunny 
available: ae Se ee ee ee 
roat () returns (directory) ara nedaeeeie 
Get root directory, which is always open (this. ‘operation does not 
require porses3t00): 


get_parent (directory), returns (directory) afonets, (Hone, ‘air. “¢losed) — 
Get parent directory, signalling nang Jt. the. 8 Jer dtrectory - is the 
root directory, and dir_closed if the ‘given frec ee is'closed. ~ 


get_size (directory) returns (int) signals. (dip ¢1og 5g) 
Get number. of eotetes. in. the. AyeA, Gi retary. siah81v ing if. the 
: EEN MES: is closed. ae Ee cee irae bites, 


Per yz rt 


0:9 523 


“Get name of the given ari de SSlanalt tna the. directory is 
closed. , . ees 


is_open. (directory) returns (bool) = aan 
Return true if the given directory. is. open, false. "" it fs not. 


info (directory, string) returns (bool, int, bool). 
signals. (none, dir closed) 

Return, information about the named. entry: a hooTean inidicating the 

kind of entry (true if entry is a file, faise if fot), the size (in 

pages if a File, . qumber of etek Sine’ aapeove and .a boolean 


iG rss? #49 


next (directory, string) returns (string) , "signats: (none, dir _closéd) 
Get next entry name after named entry, using $tring ordering. § — 


open_private (directory, string) returns (file) 
Signals (none, opened, dir, vclasedy eas . 
Open named file. in given, directory . for” “sole use, signalling 
appropriate errors: if they. occur, eae ee 


Ape 4 
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open_public (directory, string) returns (file) 
signals (none, locked, dir_closed) 
Open named file in given directary for shared use, signalling 
appropriate errors if they © occar” (Vocked. is” alee e entry AS 
open for sole use). : 


open_dir (directory, string) returns (atrectory) 
signals (none, dir_closed) 
Open. named child directory in given directory, signalling appropriate 
errors if they occur. 


close (directory) signals (dir_closed, open_entries, aati. ; 
Close the given directory, ‘ee Ais Ait As. ‘the root, or it ts 
already Closed, gr open entries exist. © a 60 a 


add_dir (directory, string) 
signals (nos tom: ‘duplicate, bad_ name, dir. closed) 
Add new (empty) child directory. entry with given ‘mame. signet if 
there is insufficient room, an existing file or directory: of the same 
name, a bad directory name given, or ine aireckory is closed, 


add file (directory, string) ie re # 
signals (no_room, duplicate, bad_name, dir_closed) 
Add new (empty) file entry to directory. Signal if there is 
insufficient room, an existing file or™ dtrectory of the same name, @ 
bad file name given, or the directory is closed. 


delete (directory, string) signals (none, opened, d¥r_ctosed)* 
Delete named entry in given directory, “signalling ‘appropriate errors. 
If entry is a directory, all of its” entries are deleted as welt. 


There are four classes of operations requiring possession: 


Fixed info: can overtap with any tut sol@ access” 
Variable info: can overlap with variable or fixed info access 
Opening: “Can overlap with fixed info acces. 
Sole: _ can not overlap ay ane 
The operations in each class are: 
Fixed info: get_parent, get_name, is_open 
Variable info: get_size, info, next . 
Opening: open_ private, open. _pubtic, open_ dir 
Sole: close, add_dir, add. [ tite, delete, — 
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the intended effects of the operation. After the operations: have been described, we 
divide the operations into classes based on which’ operations may overlap in execution 


with which other operations (when executed on the sathe serializer object). 


One way to design a system that involves concurrency is to design it for a 
single-process system first, then add multiple processes for portions of tasks that can be 
performed concurrently, and add serializers to control access to shared objects. In the 
file system example, however, we have assumed that the file system would be heparan 
by multiple processes. This assumption has influenced the choice of operations, 
especially in providing for opening and. closing: of files, Even:so, the simgle-process 
model of design is useful. Concurrent execution‘of operations:is only permitted where 
the effects on the state of the files are the same as some:serial execution of operations 
where concurrent execution is prohibited. It- may not be: possible to obtain the. 
maximum concurrency in this fashion, since certain operations could be allowed to 
execute concurrently in part. But increased concurrency is purchased at the cost of 


increased complexity. 


One simplifying assumption has been made regarding file objects that may 
appear to be unrealistic. That is, a file on secondary memory has at most one file object 
in primary memory controlling access (this is also true for directories). Unfortunately, 
this allows a user to open a file once to obtain the controlling object, then close the file 
several times, thereby completely closing the file to. access by other processes. To 
remedy this, in a real system. it would be desirable to have a second level of indirection 


for files such that every successful execution of an open_public operation returned a 
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unique controlling file object. The additional level of file object would be used to 
create a separate file object for each open_public operation, such that the file abstraction 
presented to the user would only allow a file abject to be closed once. A full 
presentation of both levels of file has no advantage over a presentation of a single level, 
so we only discuss the system_file version of files, which is sepporied by the file cluster 


and its associated serializer. 


7.2 File and directory serializers 


Figures 10 and 11 on the following pages. present. the directory and. file 
serializers. Note that we have added. several operations. that are "hidden" to the 
“normal” user. We would expect access to:these operations to be regulated through 
some library mechanism, such that a normal user would see a subset of the interface of 
an abstraction, while a "privileged" user woud be allowed to access more of that 
interface. In some cases,.and in particular for this file system, aceess to privileged 
operations would be restricted to only allowing use by implementations of particular. 
abstractions, rather than allowing access based on the identity of the person using the © 


system.'8 


18. Sach protection could also be provided to some extent by establishing a block structure for clusters 
and serkilizers. We have chosen to retain CLU's appronch to Odes. and assume that protection is 
accomplished by other means, 
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Figure 10. File serializer 


file = serializer is 


% The following operations are publically available. 
get_parent, % get parent directory —_ 


get_name, % get name of file 

get_size, .% get # of pages in file 4 

is open, % test open-ness of file © : e 

read_page, % read a page : 

write_page, % write a page a 

close, % close file 

add page, % add a page to end of file - 
% 


rem_page, remove a page, from end of tie 
% Note: delete can only be called from. sirectorypietote. 
delete, % delete the contents of a file ° 


% The wrap operation can only be used by the _file cluster’ 
% to turn a _ file object into, a file Serjalizer. op gect... 
wrap tne 


iy 
Pogpantiigmyt bess. tf fes.d 2 egescocne 


oo 


% The operations with cvt arguments .can be Split inté ‘four 
% classes, depending on which operations ‘can® overtap in 
% execution with which other operations. 


% - Class - -- Overlap - ae 

% Info: Info, Read, Write me 

% Read: Info, Read 

% Write: Info ‘* ba, Heine te 

% Sole: = UO tee Ni iecSoeniey Tas ze, 

2s 

% -Class-  §  - Members ~~ et eee ae 

4% Info: get_parent, get_name, get_ size... is is_Ypin 

% Read: read page 

% Write: write page. gut ee Be 

% Sote: close, add _page, Fem a 08. Pelete 

rep = struct[slow_ q. fast_ q: queue, ais vee oe 
- sole_c, write _c, read. c, “Tato. c; crowd, 

f: file} . ee 


wrap = proc (_f: file) returns (evt) 
return (rep$({f: f, fast_q, slow_q: qislesceeate i: 


ate 
ers 


sole_¢, info_c, read_c, write_c: trowd$create( )}) 


end wrap 


get_parent = proc (f: cyt) returns (directory) 
signals (file_closed) 
enqueue f.fast_q until crowdSempty(f. sole ce). 
join f.info.c 
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return (_file$get_parent(f.f)) resignal file ctosed 
end 
end get_parent 


get_name = proc (f: cvt) returns (string) | 
signals (file_closed) 
enqueue f.fast_q until crowdSempty(f, sole. 0). 
join f.info_c 
return (f.f.name) resignal file. closed 
end 
end get_name 


get_size = proc (f: cvt) returns (int) 
signals (file_closed) ; 
enqueue f.fast_q until crowdSempty(f. sole _c) 
join f. info_c. 
return (f.f.size) res ignal tile closed - 
end 
end get. size 


is open = proc ‘(f: cvt) returns {hoot} 
enqueue f.fast_q until crowdSempty(f.sole _c) 
join f,info_c 
return (_ fileSis _open(f. mM 
end 
end is_open 


read_page = proc (f: cvt, index: int, p: page) 
signals (file_closed, bounds) © 
enqueue f.fast_q until crowdSempty(f. sole_c) 
& crowd$Sempty(f.write_c) 
join f.read_c 
_fileSread(f.f, index, page) resignal file_closed, bounds 
end read | page 


write_page = proc (f: cvt, index: int, p: page) 
signals (file_closed, bounds) — 
enqueue f.slow_q until queueSempty(f.. fast_q) 
enqueue f.fast_q until crowdSempty(f. sole _c) 
& crowdSempty(f.read_c) & crowdSempty(f. weite_ a 
join f.write_c 
_fileSwrite(f.f, index, p) resignal file_ciosed, bounds 
end 
end write page 


close = proc (f: cvt) signals (file_closed) 
enqueue f.slow_q until queueSempty(f.fast_q) 
enqueue f.fast_q until crowdSempty(f.sole_c) 
& crowdSempty(f.info_c) & crowdSempty(f. read _c)- 
& crowdSempty(f.write_c) 
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join f.sole_c 
_file$close(f. f) resignal file closed” 
end 
end close 


add_page = proc (f: cvt, p: page). 
signals (file closed, no room) 
enqueue f,stow_q until queueSempty(f. fast_q) 
-enqueue f.fast_q until crowdSempty(f.s0le_c) 
& crowdSempty (¥.info''c) & trowibempt y(t. read c) 
& crowdSempty(f .write_c) 
join f.sole_c re 
_file$add | page(f.f,- Pp) resignal rite closed, no foom ° 
end ; 
end add page 


rem_page = proc (f: cvt) 
signals (file closed, no room) = © 
enqueue f.slow_q until queueSempty(f. fast. 8) 
enqueue f.fast.q until crowdSempty(f .sole c) 
& crowdSempty{{:tafo_c)& crowdSemptyt i. read_c) 
& crowdSempty(f.write_c) , 
join f.sole_c 
_fileSrem _page(f. f, Pp) resignal: rie eT lotee. _RO_room 
end- 
end rem_page 


% Note: called by dir$delete 


delete = proc (f: evt): 
signals (file_open, file _deleted) : 
enqueue f.slow_q until queue$emptyff. fast_.q) 
enqueue f.fast_q until crowdSempty(f.sole‘e) 
& crowd$Sempty(f.info_c) & crowdSempty(f. read _c) 
& crowdSempty(f.write_c) 
join f.sole_c 
% Note: use hidden eiATea dene te issaranien 
% to delete contents of file. | fesdetene is 
Z-only® used by PileSdeleter: wae 
_fileSdetete(f:f, 'p} réstgnat ftte- Japen: file. deleted: 
end 
end delete BSED 


end file 
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Figure 11. Directory serializer 


directory = serializer is 
root, 


get_parent, 


add file, 


% get root directory 
get parent directory. 


add new file entry 


% 
get_name, % get name of directory ., 
is_open, % test open-ness of. directory. 
get_size, % get # of entries. coe 
info, %. return.info about named entry - e 
next, % get next entry name after. named ‘entry 1 2 
open_private, % open file for sole use a 
Open_public, % open. file for sharing ; 
open dir, % open sub-directory 
close, % close this directory 
add _dir, % add new sub-directory entry 
a 
% 


delete, 


delete named. entry. 


% The wrap operation can only be. used by the _dipectery. cluster 
% to turn a directory object ingor i. dieectorysenializer object. 


wrap . - 
% The. operations can-be split into six classes, depending on 
% which operations can overlap in execution with which- other 
% operations. 
4% - Class - - Overlap - 

% Root: Root, Fixed, Variable, ‘Opening, Sole 

% Fixed info: Root, Fixed, Variable, Desens: 

% Variable info: Root, Fixed, varseeie 

% Opening: Root, Fixed - 

% Sole: Reot 

% - Class - - Members 7 

% Root: root 

% Fixed info: . get.parent,. get_name,.is _open, get_ size 
% Variable info: “info, next. . 

% Opening: open_ private, ene; public, open: dir 

% Sole; . > s Clase, add din, add_fite, delete. 

rep = struct[slow_q, fast_q: queue, 


sole_c, open_c, var_c, fixed _c: crowd, 
dir: directory] 


% The wrap procedure is used by the directory cluster 

% to turn a directory object into a directory serializer 
% object. This operation can only be used by the 

% directory$root and directory$add_dir operations. 


“wrap = proc (d: directory) returns (cvt) 


re 


turn (rep$create{dir: 4d, 
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slow_q, fast_q: queue$create(), 

sole_c, open_c, var_c, fix_c: 
crowd$create( )}) , 

end wrap ie 


root = proc () returns (directory) ; 
% note: -directory$root uses the wrap operation. 
return ( _directorySroot(y) AGN Faudytulagat b 
end root NEARS We ew 045 


get_parent = proc (d: cvt) returns (directory) 

Signals (none, dir_closed) 

enqueue d.fast_q until ser oncsoumey (a: sole. ar 

join d.fix_c 
return ( _directory$get paréattd: airy). 

resignal none, ‘dirleTosed: ze 

end 

end get_parent 


get_name = proc (d: cvt) returns: (string) . 
signals (dir_closed) 
enqueue d.fast.q until crowd$empty(d.sole_c) 
join d.fixed_q 
return ( “directorySgot_ name td: ee seta dir_closed . 
end ; 
end get_name 
is open = proc (d: cvt) returns (bool) » 
enqueue d.fast 7 until crowdSompty (4. sole _) 
join d.fixed.q” 
return (_directory$is closed(@. @iryy 
end 
end is_open 


get_size = proc (d: cvt) returns (int) 
signals (dir_closed) 
enqueue d.fast_q until crmmusenet yes: sole a 
join d.var_c 
return (_ directory$get_ size(d: airy). rTesignal: dir_ closed 
end re 
end get_size 


info = proc (d: cvt, name: string) Wise 
returns (bool, int, bool) signals (none, dit_closed) = - 
enqueue d.fast_q until crowdSempty(d.sole e) 
& crowd$Sempty(d. open_ my fe RE Oy 
join d.var_ic gS aH are Sue 
file_ness: bool, size: tnt, ‘open! ‘ess: boot - : 
:= _directory$info(d. dir} resignal dir_closed, none 
return (file ness, size, net ness) ; 
end 
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end info 


next = proc (d: cvt, name: string) returns (string) 
signals (none, dir_closed) 
enqueue d.fast_q until ruin ae ol sole -*) 
& crondSempty(d. open. c) Ae . 
join d.var_co 
return ( Ugivectocysoet.: next(d, .dir)). 
resignal dir_closed, none 
end 
end next 


open_private = proc (d;.cvt, name:. ‘striag) returns. (tite) 
signals (none, opened, dir_closed) 
enqueue d.slow_q uatil: queveSempty(d,fast_q) . 
enqueue d.fast_q until crowdSematy(d. sole. 7c) 
& crowdSempty(d.open_c) 
join d.open_c 
return (_directory$open_private(d.dir, name)) 
resignal dir_closed, none, locked. 
end 
end open private 


open_public = proc (d: cvt, name:. string) returns. (file) 
signals (none, locked, dir_closed) 
enqueue d.slow_q until queve$Sempty(d.fast_q) 
enqueue d.fast_q until crowdSempty(d.sole —*) 
& crowdSempty(d. open Cc) ; 
join d.open_c 
return (-directory$open_public(d. dir, name) ). 
resignal dir_closed,. none, locked 
end 
end open public 


open_dir = proc (d: cvt, name: string) returns. udiractory) 
signals (none, dir_closed) 
enqueue d.slow_q until queueSempty(d. fast_q) 
enqueue d.fast_q until crowdSempty(d. sole_c) 
& crowdSempty(d.open_c). 
join d.open_c 
- peturn (_directorySopen_dir(d.dir, name) ) 
resignal dir_closed, none 
end 
end open _dir 


close = proc (d: cvt) 
signals (dir_closed, open_ entries) 
enqueue d.stow-q until queueSempty(d.fast_.q) 
enqueue d.fast_q until crowdSempty(d.sole.c) 
_ & crowdSempty(d.var_c) &. crowd$empty(d. f.ix_c) 
& crowd$empty(d.open_c) 
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join d.solec 
~directorySclose(d. sir) resignal ‘dir: closed, open _. entries 
end : 
end close 


-add_ dir = proc (d: cvt, name: string) " ue 

Signals (no_room, duplicate, bad name, dir_ closed) 
—% note: directary$add_di* uses the wrap operation . 
enqueue d.slow_q until queueSempty(d.fast_q) 
enqueue d.fast.q. until cromtSanptytd-sete.c)- 

.& crowdSempty(d.var_c) & crowd$empty(d. open. ee 
join d.sole_c 

_directorySadd.. dir(d. dir). : 
resignal no_room, duplicate, bad_ ‘name, dir_ closed. 

end 

end add_dir 


‘add file = proc (d: cvt, name: string) : 

signals (no_room, duplicate, bad name, dir closed) 
enqueue d.slow.q until quevehempty(a. fastiay 
enqueue d.fast_q until crowdSempty(d.sole_c) 

& crowdSempty(d.var_c) & crewdSempty(d.apen_c). 
join d.sole_c 

_directorySadd_ file(d.dir) ss 
resignal no room, duplicate, bad_ nai , ‘dir_closed 

end 

end add_ file 


delete = proce (d: cvt, name: string) 2 
Signals (none, opened, dir_closed) 
enqueve d.slow'q until queve$empty(d:fast_q) 

enqueue d.fast_q until crowdSempty(d.sole_c) 
& crowdSempty(d.var_c): & ccowdSempty({d.fix_c) 
& crowdSempty(d.open_c) 

join d.sole_c 

_directory$delete(d. dir) resignal dir. closed, ‘open_ entries 

end 

end delete 


end directory 
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To distinguish between the data abstractions and the sertalizer- abstractions of 
the einer interface, we will use the names ey ee fi le. fot ‘the serializer 
abstractions, and _directory and _file for. the. data anEACHOSS o fhe, user, in a multiple 
process system would : only. be allowed ‘to ‘0c athe operations of he § eerializer 


abstractions, which would utilize the operations ofthe data abstractions. 


In the above twa. serializers, there are clase Upbiitiony cn can be strictly 
ordered on the basis of the execution of any operation from one class excluding the | 
execution of any operation from another Class. ‘The-order:i is. fom most permissive to 
least permissive, with operations that: retwer: ‘mforihation ‘generally being: the most 
permissive, since they can be “executed” ‘coficurentty.. Phis ordering: allows us to 


construct serializers that follow the ane ee of’ ‘the ) - wild ‘Writers robe If an 
considered to be a.reader; otherwise it a. ‘writer. . dn the above, serializer, .we. have. 
adopted a readers priority approach, with the information gathering, ‘operations having 
higher priority. It would be’ equally: correct to adopt é FIFO ‘approactt or a‘writers 


priority approach, but different performance would result. 


The restrictions on simple serializers must be relaxed lightly to allow us to 
write the file and directory scrializers. The most important addition is ‘the exception 


mechanism, which includes a signals clause in the operation interface and a resignal 


clause at the end of any statement. This addition does not greatly add to the complexity. 


of our model, since we only use the exception mechanism in the same manner as the 
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return statement. !? 


We retain the important limitation, which is to return or signal directly after 
invoking the operation of the data abstraction, The other. addition is. to allow local 
variables, which we use-in directorySinfo to hold the results of an invocation that returns 
multiple objects. The effect of this addition is also minor, since we immediately return 


those results unchanged. 


7.3 Specifications for file and directory serializers. 


The specifications for the file and. directory serializers are similar to the 
readers priority readers-writers problem. Therefore, we -will:only. present illustrative 
examples, rather than full specifications. One «useful abbreviation is to use the first 
letters of the operation classes, rather than the operations, to name transactions. This 
gives us the following transaction names for file operation classes: 

I: an Info class transaction : 
a Read class transaction . 


a Write class transaction 


Ye RP 


a Sole class transaction 


For directory operation classes, we can use the ;same spegfications, except that the 


19. In CLU, when an operation signals an exception, the invocation terminates, and the dmmediate 
caller is given the opportunity to handle the exception. A common method of handfing’ an exception ‘is to 
reflect it to yet another level via resignal, An invocation that signals an exception is not resumed. For 
further details, see [I_iskov 79a]. 
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transaction symbols have the following interpretation: 
I: a Fixed Info class transaction 

R: a Variable Info transaction 

W: an Opening class transaction *~ 

S: a Sole class transaction 
In the remainder of this section we use the class lames of the file setidlizer (Info, Read, 
Write, and Sole) with the understanding that the remarks ald ‘apply: to ‘the 
corresponding directory classes. 


The most important specifications are those that relate to the exclusion of 
certain operations by others. If these-specifications are violated we. obtain invalid result 


values.. The complete exclusion specifications are:> 


I-join ¢ S-join D I-leave < S-join 
R-join < W-join > R-leave < W-join 
R-join < S-join D R-teave < S-jain _ 
W-join < R-join D W-leave < R-join 
W1-join < W2-join D W1-leave < W2-join 
W-join < S-join 3 W-leave < S-join 
S-join < I-join D S-leave < I-join 
S-join < R-join D S-leave < R-join 
S-join < W-join D S-leave < W-join 

Sl foin’< S2-join D Sl-leave <S24join 


A number of priority ee ae be proposed, The readers priority 


specification used in Chapter | a Is: 
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Wt-enter < W2-enter < R1-enter < W1-join D.Rl-join.< W2-join 
The same specification clause ‘folds for the-file and directory: scilafiners: ‘To give more 
complete priority specifications, we introduce two new classes of. transactions; SW, 
which contains all Sole and Write transactions; and IR, which contains-all Info: and 
Read transactions. Using these new classes, the priority specification becomes: ? 


SW1-enter < SW2-enter < IR 1-enter < pais 
> IR1-join <SWasoin._. 


The following specification specifies concurrency for Read transactions, and is 


a slight adaptation of the concurrency specification in Chapter 6: 


Rl-enter < R2-enter < R1-leave 
& GX(R1-enter, R2-enter, W*-enter) 
& GX RK l-enter, R2-enter, S*-enter) 
2 R2-join < Rl- leave 7 . | 
The difference lies.in the addition of the exclusion of ester events from the Sole class of 
transactions. The above specification can also be proven for Read and Info transactions 
by substituting R for R1 and I for R2 to get one clause, and | for R1 and R for R2 to get 
the other. Finally, the following specification indicates wher’ a Write transaction must 
Srrsap vain an Info transaction: | | | 
W-enter < I-enter < w- leave 


& GX(W- enter, I-enter, St-enter) & GX¢W-enter,| I- -enter, - Went 
> I-join < W-leave é | s 


-170- 


The service specifications are as simple as: for the readets-writers problem: 
each request must receive a reply.. The service.specifications.are: _ 
@I-enter > @l-exit 
@R-enter D @R-exit 


@W-enter > @W-exit 
@S-enter > @S-exit 


We have shown that the specifications for the file anid:directory:serializets are . 
similar to the readers priority example used in Chapter 6, This may not be Surprising, 
since the problems and solutions are similar, but the lack of such’ a ‘surprise is Pree 


one of our goals. 


One point about the specifications that we haye discovered through the above 
example is the usefulness of dividing the operations? intorelaates; sand! (providing the 
specifications for the classes rather than for the single pout Using class-oriented 
§: while’ retaining’ the 


specifications promises to provide moré’ concise ‘specifica 


precision we desire. 


The verification techniques we discussed i in Chapter 5. and, Chapter 6 remain 
valid for both the file and directory serializers. The only. additions we would make 
would be to introduce classes of operations into the verification as we have for the 
specification. When two serializer, soperauons are suff ciently” similar it should be 
possible to use the proof of one in the proof of the other, as iS ‘the case. for file 
operations in the same specification class. We will not propose techniques for 


_ determining how much similarity is sufficient, although we regard the issue as being 
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worthy of further research. 


7.4 Guidelines for‘addition of serializers 


In a system where data abstractions are used, we believe it likely that some 
library of abstractions will become useful, and-eventually indispensable. Further, we 
consider it likely that many of these abstractions will be initially designed for a 
single-process environment.” If we are to use these data abstractions in a 
-.multiple-process environment, and the eoremending cbiecis'aré to be cared between 
processes, we can either rework the abstractions for that purpose, or we can: provide a 
mechanism for controlling concurrent access that: requires‘ no change to the data - 
abstractions. ‘The serializer construct was designéd along’ the latter:lines, ‘This section 


discusses how that approach could be made ‘largely automatic. 


As a first approximation, we assume that each operation has exclusive use of 
the resource, then introduce serializer abstractions as replacements for aks abstractions 
in order to permit concurrency while prohibiting conflict'and: deadlock. This is.a simple 
strategy, and is not intended - cover all situations, although swe believe it to be an 


important first step. 


When a serializer abstraction is substituted fora data‘abstraction in a program, 


yet the data abstraction is retained as part. of. the:.implementation. ‘of the serializer 


20. Even if for no other reason than programmer inertia. 
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abstraction, we may be faced with problems that result from having-two abstractions in 
the place of one. If we wish to integrate a newly serialized abstraction into a system that 
has been created with the old data abstraction, we.need.a linking mechanism that will: 
allow the operations of the serializer abstraction to be substituted for operations of the 
- original abstraction in old er programs. If the interface to the serializer abstraction is 
compatible with the interface of the original data abstraction, and both abstractions 
have isolated representations, then this linkage mechanism allows suai upgrading of 


programs that use the original data abstraction. 


However, the representation of the original data abstraction is exposed to the 
operations of that data abstraction. Here the splitting-of the original abstraction is more _ 
difficult. In most cases, we expect that .an.automatic “rewrite” of the data abstraction. 
would be easi'y made by a program. If we call. the. type introduced by the data 
abstraction DA, and the type introduced by the serializer abstraction SA, then the 


following rules allow such an automatic rewrite: 


* Occurrences of DA in the cluster for DA are changed.to.SA, including 
occurrences of DA in the interface of operations of DA, provided that 
they do not result from uses of cevt. Thus, a: component of the 
representation of DA that was an object of type DA would become an 
object of type SA. In the file system example, this would be true for the 
case of the get_parent operation of the directory abstraction, since the 
get_parent operation of _directory (DA) must return a directory object 
(SA), and not a _directory object (DA). This is also truc of the 
open_private, open_public, and open_dir operations, 


* Operations of DA that have evt appearing in their headers must have DA 
appear in the interface specifications where a corresponding evé appears 
in the operation header. These are operations.that.explicitly access the 
representation of DA, so a conversion of DA to SA is not reasonable. 
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* The up and down operations convert between the representation and the 
_ DA type, not the SA type. This is consistent with the treatment of cvt. 


* We introduce an operation, called wrap,. that. takes a.DA object.and | 
returns.a newly created SA object that encapsulates the DA object. The 

. wrap operation is used to create a new SA object in operations that create 
new DA objects and need (due to our. first transaformation) to use SA 
objects, 


Tf the above translation results in a type error then the automatic rewrite is not 
performed, and a manual rewrite must be performed. Such a case could arise from an 
operation that accepted an argument of type DA, then explicitly used, down to attempt 
to access the representation. The transformation would have changed the use of. DA 
into SA, but the down operation would only. work for an object of type DA, and fails 
(due to static type checking) with an SA object. 


In addition, a data abstraction may have to be rewritten if it supports cyclic 
objects. If operations of DA call operations of SA, which in turn call operations of DA, 


me 


a cyclic data structure can cause deadlock by. having access to an object being blocked 


by. an incomplete access to the same object by the.same process. Access to cyclic objects 


is discussed later in this chapter. 


“There are two reasons to believe that a rewrite of the original data ‘abstraction 
will not be a difficult process even if it cannot be done automatically. First, the amount 
of detail to be changed is likely to be small. After all, the intent of the data abstraction 
has not changed. There is only the additional distinction between serializer abstraction: 


and data abstraction. Second, we believe that it will be rare that any code except for the 


_ 
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implementation of the serializer and data abstractions will be allowed to use. the data 
~ abstraction. The intention of this fransfarmalion | is to make ‘the rest of the en use 
the serializer abstraction. Therefore, the riumber of places’ to be changed is also likely 


to be small. 


In the file system example, there is a case where the use of the saitomade 
splitting of types may provide serializers where none are needed. In particular, if the 
directory information is implemented using a’ file, then the setializer for the directory 
may provide sufficient protection for the fite object tised to implement the direttory. In 
such a case, the transformation from DA to SA would ptovide'an unnecessary level of 
serializer. A rewrite of the _directory cluster would then be desirable to promote: 
efficiency. This efficiency argument actually works'in favor of our sepatation of data 
and serializer abstractions, since if they were inextricable; the optimization descrited 


could not be performed. 


The above rewrite process has been applied to the file and _directory: 
serializers. In" particular, the operations” “_Gitectory$open_private and 
_directory$open_public now return file objects, which“ ate ‘stipported’ by the file’ 
serializer. Further, the operation _directory$open_dir returns a directory object, which 
is supported by the directory serializer. The wrap operations shown in the file and 
directory scrializers are used to enclose a file or directory object i ina file or directory 
serializer. The wrap Operations are. used whenever a new file or _directory object is 


created. 
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In any reasonable implementation of the:..directory:eluster there will be a list 
of the open files and child directories’ for any _.directory object. . In this case, the 
automatic rewrite we mentioned above informs us of a type conflict: the list of open — 
files and directories must. be for the file and disectory: objects ‘supported. by - the 
serializers, and not the _file-and._directory objects supported by the.clusters. 


75 Higher-level transactions | 


‘Suppose procedures P and Q use operations on a shared data object X of type 
T. We have recommended that a serializer object should be introduced for X to ensure 
that the operations of T performed on X do not interfere with each other. However, the 
user may intend that P and Q do not overlap. The serializer for object X does not 
enforce this restriction. One solution is to introduce a further encapsulation of X in 


order to perform operations P and Q such that they do not overlap. 


A difficulty with the introduction of further abstraction levels is that the 
designer of a system may not know how the user will be using the system, and cannot 
provide the appropriate abstractions in advance. This inability to forecast is certainly 
present in our file system example, since the user may wish to have a process perform 
several operations on a file (or on several files) such that no other process will access the 
file (or files) while those operations are being performed. The file system example 
provides no solution to this problem in gencral, although we can attack certain special 


Cases. 


- 176-: 


': A limited solution to the above problem-can be achieved-by adding a new 
operation, update, to-the file serializer. Fhe text-of this operation is shown in Figure 12. 
The update operation: performs a sequence of read operations.an:a file; then performs.a 
computation. supplied as a: proeeduse by the ‘user/on date! supptied ‘by: the user, then 
performs a sequence of writes on the same file. In: oun:sitiple solution, the entire. 
update operation is performed without allowing overlapping reads or writes on the file. 
If more concurrency is desired, update operations that do not haye.overlapping. sets of 
pages can be permitted to piece. in parallel, anieri that the underlying _file 


abstraction will pert this. 
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Figure 12. Update operation 


aS OR Be Se AR Bee te 


The update operation is intended to perform a sequence of 
reads, an arbitrary computation, aad a.sdqueace of..writes:. 
The entire procedure should executed without overlapping 
other write: operations -or.other. update. pperations. This 
procedure resignals an error on reading or writing, or an 
abort error from the arb procedure. -.An error that is 
resignalled after the first writé tas been finished will 
leave the writes only partially completed. 


update = proc [dt: type] 


(f: cvt, reads, writes: spair, arbi! pt, data:: dt): 
slanels (file_ closed, pounds ae 


pair = struct [pgnum: int, pg: page] 
spair = sequence [pair] 
pt = proctype (dt, spair, spair) ‘signals (abort) 


% wait for write access to resource to be OK 
enqueue f.stow'4 until: ‘queueSempt y—(f. fast _q): 
enqueue i fast _q hada Pete tebnba ed (f.sole_c) 


'& crowdSeémpty: (it. werke_c) 
& piteibedsd (f. reed -¢) 


% join the ceoud to show that. we “are going to. write 
join f.write.c _— ae 


% perform the reads into the given memory. pages 
% from the given ‘file pages © 
for p: pair in WnoG cepa saa) do 


end 


% perform the arbitrary computation 
% (modifying the given memory pages) 
arb(data,. reads, writes) . 


‘% perform the writes from the given. gece pages 
% into thé given fite pages ~ " 
. for p: pair in spairSelements(writes) do 
_FileSut ett of, pipghule; Pepg peo: 
end 
end resignal file_closed, bounds, abort 


end update 
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8. Conclusions 


In this thesis we have been concerned with verifiable control of concurrent 
access to resources, In this pursuit we have presented a “tanguage construct for 
controlling concurrent access, a definition of the semantics of _ this construct, a 
specification language for describing varieties of Gencinciey Guntiol for instatices of 
the construct, methods: to verify that instances of the construct satisfy their 
specifications, a program for performing this verification automaticaly, and a 


discussion of some of the interactions possible between itrstances of this construct. 


In separating the control of. concurrency ‘from the. data access, we have 
attempted to apply this: separation ta the programming language, the semantic model, 
the specifications, and the verification evden The objective has been to modularize 
the construction and verification of programs involving conicutrency. By this. 
modularization, the problems associated with construction and verification become 
more -tractable. The results: of.our .research indicate that this. modularity can be 


achieved, at least for the simple serializers we have discussed. 


In this chapter we discuss how extensions to sérializers require extensions to 
our verification techniques. Most of these. extensions Fequire significant further 


research. Then we present closing remarks to sum up the contributions of this thesis. . 
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8.1 Verification of serializer extensions 


In this section we briefly consider how extensions to serializers affect our 
semantic model and verification ‘methods. This is the area where further research is 
most neeescaiy and most difficult. Our success in verifying simple serializers can be 
largely attributed to the limitations we have imposed. We believe that fu rther success in 


verifying concurrency control ties in selective relaxation of these limitations. 


8.1.1 Adding boolean variables and boolean expressions. 


To add simple boolean variables and boolean expressions to serializers 


requires the following changes to the semantic model: 


Bit. Sd” ot 


* The node.graphs must be extended to handle declaration and assignment 
of boolean variables. These variables must further be distinguished as ~~ 
either local variables, which are instantiated op: each: ansaction;.or 
global variables, which are components of the serializer representation. 

*The semantic equations must be extended to handle evaluation of 
boolean: expressions. This will require: examining, finite, historics for the 
last assignment to any boolean variable. One of the most important 
changes to évaluiation is:that evatuavérnanustinkt placd inthe contextofa 
transaction, since expressions may involve local variables. 


* There must be some: indication of the initial: state-of a serializer object. 


This is easily accomplished by representing the serializer stale as the 
‘result of some initial assignntents tO represontatida components. —- 
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To illustrate the kinds of serializers and verifications that-are possible with the. 
addition of boolean variables, consider the case where we are limited to boolean 
variables as part of the representation, and the only legal boolean expressions are true, 
false, and simple components of the representation. As an 1 example, we present the 
following abbreviated serializer: | - 

xop = proc (x: cyt, ...) 
enqueve x.ql until x. & crowdSempty(x.c). 


join x.c; ...; end 
x.b := false 


end xop 

yop = proc (x: cvt, ...) °° oe EB 
enqueue x.q2 until ~x.b & eepeaan le. é 
join x.c; ...; end 
x.b 1% trug .-: 
end yop 


Suppose that x.b is initially true. We would like to prove that the number of 
executions of} xop is equal to or one greater thant the Bumiber of ¢ executions of yop. This 


specification could be written as: 


(#X-exit = #Y- -exit) | (#X- exit = = #Y-exit + oe 


Informally, suppose that the above specification is: not sisted, and that it is: due to 
# X-exit > #Y-exit + 1.. Then there: must be: two. events ‘Xa-exit CX2-enit that occur 
without an intervening Y- -exit. Note that the x.b is set to false after X1 ‘Jeave, and 
remains false untit after some Y-leave. If no such Y-leave: event OCCUFS;. ae the 
guarantee remains false, and X2-dequeue cannot, occur, Therefore, ‘there. can be no 
such events. To prove that # Y-exit cannot excecd #X-exit, we note that the only way 
that #Y-exit could exceed #X-exit is for the initial exit event to be some Y-exit. 


However, we assumed that the variable x.b was initially true, which prohibits 
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Y-dequeve from occurring, 


The addition of boolean variables provides additional information about the 
past execution of operations. As the above. informal proof shows, the semantic model 
can capture this information as well. Extending the verification rules to handle ‘such 


situations is left as a topic for future research. 


8.1.2 Conditionals 


The addition of boolean variables and expressions is of limited usefulness if 
the only. test of a boolean. expression. remains::limited to.-tae guarantee.on a queue. 
Another extension that can be:added at. this. point is. conditional statements, with the 
form 

if expression 

then body_of_statements 

else body_of_statemenis 

end 
The else part is optional. In the semantic: ttiodet:-we need to introduce @ new kind.of 
node, the if node. The if node tests the resufts-of the bodlean expression ‘(we will 
discuss a more general model for evaluation below), and conditionally executes the 
appropriate body of statements based on the result. The next node after the last node of 
either the then body or the else body is the node that corresponds to the statement 
directly following the if statement. By the introduction of conditionals, the 


"node graph" has become a true directed graph. 
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Although the modelling of conditionals poses no severe. difficulties, the. 
addition of conditionals complicates the Spesiication language. Consider the following 
operation (we have also related our requirement for a “strict # comespotdence between 
serializer and resource operations): | pone —, 

xct = proc (x: “evt; d: data) 

enqueue x.q until crowdSempty(x.c). 

if data$cond(d) 

then join x.c 
resource$fast_xct(x.res, d) 
end 

else join x.c 
resource$slow_xct(x.res, d) 
end 


ead 
end xct 


What event does X-join denote?- There. are potentially two: different events, and the. 
event to occur depends on the data presented'to the operation: 


The solution we recommend is simple: for every test in a conditional 
statement, assume that the test evaluates to a particular boolean value (true or false). If 
the specification clause can be verified for every permutation of the conditional tests, 
then it is verified for the operation. In the above example, we would effectively need to 
verify two operations: one where data$cand(d)..was true immediately after the enter 
event, and one where data$cond(d) was false. 
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~. 8.1.3 Loops in serializer operations 


. Just as-conditional statements introduce. ambiguity about which nodes can be 
executed, iteration and recursion introduce ambiguity about how often a node is 
- executed.. The doubt is significantly worse, however, since the number of possible 


executions of a loop is not bounded. 


When a point in a serializer operation. canbe passed many times during the 
execution of a transaction, an event is not just an execution of a node for that . 
transaction, but a particular execution of laa ipa We can: adapt: ‘the method of 
handling eonditionals. to handling loops by assuming particular. numbers of iterations 
for each loop. If the specifications can be ‘shown to hold: for any choice of such 
funibere then the specifications are verified: forthe arate as a whole; provided that 
all of the loops terminate. Induction can be used by. assuming. that the specifi cation 
holds for some particular number N of executions around a loop, then showing that the 
specification holds for N+1 executions (plus a basis proof for N = 0). In order to 
prove service specifications, an additional proof that each loop terminated would be 


necessary. 
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8.1.4 Arbitrary expressions and invocations 


‘The introduction of arbitrary expressions fitto seriatizers ‘has ‘the’ following 


effects: 


*The semantic model must include arbitrary types. - and. values of those 
types, including user-defined types. , 


_ * The semantic mode! must be provided with events to mark both the start 
and the end of an invocation. 


'* The specification language must. be merged; with. a larger specification 
language. Values must be named and functions on those values defined. 
Concurrency specifications, ‘data abstrattion ‘specifications, and - 
procedyral specifications may be mutually interdependent. 


* The serializer verification system must be joined to a more general 
verification system. While it is our hope that the two kinds of verification 

systems can‘be kept modular, we have no evidence at this time to support: 
this hope. 


With arbitrary expressions and invocations,.some of the verification. 


techniques we have described may be invalid for some situations, some of which are: 


* Some invocations may not always terminate. If we use such invocations, 
then we must be prepared to prove service where applicable. If we 
cannot prove service, then we are faced with a new potential source of 
lack of service: indefinite possession of the serializer object. In terms of 
our current model we would be faced with a finite complete history (since 
it would be possible for no further serializer events to occur) where a 
transaction would be in possession at the end of the history. Since many 
of our verification rules depend on no transaction being in possession at 
the end of a finite complete history, and no crowds being occupied, our 
techniques are not applicable where termination cannot be proved. The 
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problems of combining our techniques with proofs of termination for 
invocations remain for future research. 


*If we allow side effects in the evaluation of guarantees evaluation it 
becomes necessary to introduce events to model the beginning of such 
evaluation, and to indicate the order in which guarantee evaluation is 
performed. 


* Recursive operations provide one more problem. When we assume that 
an invocation used by a serializer terminates, and thereby prove service 
for the serializer operation, such a proof must not be circular. If the 
invocation termination depends on the service proof, then the service 
proof is not valid unless one can prove that the level of recursion is 
bounded. 


All of the above issues are left for further research. 


8.1.5 Priority queues 


The monitor construct presented in [Hoare 74] permits the use of priority 
queues, which obey a “first in, best out" discipline. A serializer example that makes use 


of priority queues is presented in Appendix III. 


In using priority queues, we do not (usually) wish to allow the addition of 
requests to a queue to indefinitely postpone the progress of earlier requests. For the 
disk serializer we can prove that the request operation guarantees service since, when we 
are serving one queue, its size decreases with every fulfilled request, and we assume that 
the resource operation terminates. Therefore, the queue being served must empty, the 
direction must change, and the other qucue becomes the served queue. Another proof 


of service can be based on never adding requests to a queue at a priority number less 
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than or equal to the lowest number request: in the queye? ' We can still prove service 
even if we allow a bounded number of requests to be added at a lower or equal number 
8.2 Closing remarks 


This these has: presented a: wide. range cof sapoes oft a single ee 


construct; including. “programming. language. “design... formal 3 ecification: 
programming languages, and verification techniques. We were able to cope With such a 
wide range because we were interested i in limited techniques for a limited construct, and 
our design philosophy emphasizes ‘inimet fteclerence cjeuween: ‘constructs. We 
believe that our results show that such an approach has merit. 


_In several places we Dave menos a it is Laren to view serializer 


ete Fh 


operations either as procedures or as S message ‘handlers This Alexbily i is made possible 


through the decien of the ae construct, and through the use of a semantic model: 


bie giby bys ati bye; figs 


eee a 
that is limited to describing scrializers.. Even though details may “change : as. sérlalizers 


are entbedded: in. a procedure-oriented .or a, message-passing. language, the basic . 


approach to proving seriglizers should remain sound, . 


21. This is the approach that Hoare sakes in.[Iloare 74}. 
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We have only attempted to verify atrtomatically a number of variants of the 
readers-writers problem. Partially due to this limitation we have been able to handle 
several important Specifications regarding PoneueTency Conor: Even though. the. 
specification categories have been chosen for use with access to resources, Properties 
such as exclusion, priority, and termination are generally recognized as. important in 


~ dealing with concurrent programs. 


We have demonstrated the feasibility of proving a form of termination that is. 
applicable to transactions, rather than programs or objects. This technique is especially _. 
useful when resources (or objects in general) have unbounded lifetimes and the number 


of-active transactions (or processes) is unbounded. 


Our approach to verification has not been oriented. toward presenting either a 
minimal or a comptete set of axioms and inference tutes. Rather, we have identified 
some higher-level theorems, expressed as inference niles, that are useful in proving 
serializers, and have justified these theorems by direct appeal. to the semantic model. 
Should further examples identify ‘other useful theorems, more Jastification through the 
model is called for. While the study of the completes of an axiom system is 
intersting in its own right, it is rare for a verifier {either automatic or manual) ioappeal 
to the axioms if more general and more powerful theorems are Known. The test we 
value most for such a selection of theorems is their imei in Hen HEAuON: a test sistas our 


éheorenis have passed. 
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Appendix I - Bounded buffer sertilizer 


A bounded buffer is intended to smooth variations -in..processing. speed. 
between a producer and a consumer of items‘of information, and thereby afford more 
concurrency between the two processes.” 2 A bounded buffer is accessed by get and put 
operations, where . the Nth. get, operation retrieves. the: information shat the Nth ut 
operation deposited. A bounded buffer object is constructéd “by calling the create 
operation with a Positive number specifying the number of, items of information to” 
buffer. The - -buffered information iS: transferred ty. copying ‘the contents (via 
item$move) from one item to another. “We | ‘assume ‘that. ‘this copying ‘takes: some 
significant amount of time.” ® Partial Specifications for this on appear in ‘Chapter 
4. 


The bounded_buffer serializer given below uses only slight extensions over 
~ serializers. We assume that performing a put operation on a full buffer causes an 
exception to be signalled for the data abstraction (called bbufin this example), but that 
the serializer operation simply pauses until the buffer is not full. If several processes 
perform get operations, there is no overlap between the operations, since a modification. 
to the buffer is made in the data abstraction, and the modifications made by two 


invocations could conflict. A similar conflict arises for put operations. 


22. A solution to this problem using monitors appears in [Hoare 74]. A verification of a similar monitor 
appears in [Howard 76]. 

23. Although such copying is normally forcign to CLU, we have used copying in.an attempt to remain 
comparable to the monitor statement of the problem. 


* 19S- 


The combined_bounded. buffer serializer shown in Appendix II combines the 
function of the bounded. buffer serializer and: the bbuf cluster. The interface remains 
the same, but the implementation does not | use ‘the bbuf cluster. Besides the ebvicils 
savings afforded by the elimination of operation calls from’ the gtfializer to the cluster, 
there is additional concurrency possible’ because get operations are allowed to ‘overlap 
with other get operations, and put operations are. allowed to overlap. with other put 


operations. 


We. have presented this problem as an illustration of how the modularity 
provided by serializers allows such optimization without GHANEING., the interface that the 
user sees. Further, any verification of programs that use ‘the banded buffer serializer 
remain valid, provided that they are unaffected bythe additional.concurrency. 
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% The bounded buffer serializer protects the bbuf abstraction 
% against damaging concurrent access. Get and Put operations 

% may only overtap with get. size operations... All copying. of 

% item to item is done in the bbuf crusten: 


bounded_ buffer = eerie liier is 
create, get_size, get, put . 


_ fep = struct[res: bbuf, Cc; crowd, Max: Ant, 
. gq, pq: queue} ~~ 


create = proc (n: int) returns (¢vt) signals (bad size) 
return (rep${res: bbuf$create(n), 
max: a, 
c: crowd$create(), 
gq, pq: queue$create()}) 
_ Pesignal bad_size 
end create 


‘get. size = proce (x: cvt) returns (int) | 
return (x.res.size) 
en get -siz6 


get = proc (x: cyt, dst: item) =. Lisa 
enqueue x.gq until crowaseapty (acc) a x.res. size > 0 


join x.c 
bbuf$get(x.res, dst) 
end 

end get 


put = proc (x: cvt, src: item) 
enqueue x.pq until crowdSempty(x.c) & x.res.size <= x.max 


join x.c 
bbuf$put(x.res, src) 
end 

end put 


end bounded buffer 
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Appendix II - Combined bounded buffer serializer 


% The combined bounded buffer permits get operations. to, overlap with 
% other get operations, and put operations to overlap with other put 
“% operations, but get and put operations.cannot overlap... Get_. size 
% operations can overlap with either get or put dperations.. 


combined bounded buffer = sérializer is 
create, get_size, get, put 


buf = array[Litem] 

ial = struct[res: buf, gc,pc: crowd, 
next, size, max: int, 
Sq, gq, pq: queue] 


create = proc (n: int) returns (cvt) signals (bad_size). 
if n <1 then signal bad_size end 
return (rep${res: buf$fill _copy{0,°n, item$credte(:)), 
next: 1, size: 0, max: n, 
gc, pe: crowd$create(), =. 
gq. pq, sq: queueScreate()}) 
end create 


get_size = proc (x: cvt) returns (int). 
return (x.size) an 
end get_size 


get = proc (x: cvt, dst: item) 

: enqueue x.gq until x.size > 0 & crowd$empty(x.pc) 
src: item := x.res[x.next] 
x.size := x.size - 1 


x.,mext := (x.next+1) // x.max  % take increment mod N 
join x.gc 
item$move(dst, src) % copy data from src to dst 
end 
end get 


put = proc (x: cvt, src: item) 
-- @nqueue x.pq until crowd$empty(x.gc) & x.size is x.max 
dst: item := x.res[(x.nexttx.size) // x.max] 
x.size := x.size + 1 - 
join x.pc 
item$move(dst, src) 
end 
end put 


end combined _bounded_buffer 
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~ Appendix Iil'- Disk head sctieduler : 


1 cate ep Sa tee head soucduler prebicet sais Or oe 
Below we give a serializer soliition to the ‘problem, which Uses the prlorty_ queue type, 
A priority_queue is a queue -where the order. of, dequeue. events. is. Aependent. on. the 
priority. We will assume that the lowest numerical value of the priority is. served before 


any others. Equal priorities are served FIFO. 


The algorithm used depends on. having two. queues, one which is served in 
increasing order of disk: address, called XupG: and-ene which is served.i in. “decreasing 
order of disk address, called x down.q ‘Ou algorithm works by adding requests to one 

“queue, and serving the other. We change direction whenever the queue-forthe current 


direction is empty and the other queue is not empty; eke eee 
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disk = serializer is 
create, 
request 


“pep = record[increasing: bool, 
up_q, down_q: priority_queve, 
disk: disk] 


create = proc () returns (cvt) 
return (rep${increasing: true, 
up_q, down_q: priority_ queveScreate().. 
disk: _disk$create()}) 
end create 


request = proc (d: cvt, address: int, kind: iat, pr page) 
: signals (bad_address, disk_error) 


if d. increasing 
then enqueue d.down_q 
until crowdSempty(d.c) & 
(~d. increasing | 
; priority_queue$empty(d.up_: q)) 
priority address 
d.increasing := false 
else enqueue d.up q 
until crowd$empty(d.c) & 
(d. increasing | 
priority _queueSempty(d.down oy 
priority -address 
d.increasing := true 


pgs 


‘3, 


end 
join d.c 
_disk$request(d.disk, address, kind, “p) 
end resignal bad.address, disk_error 
end request 


end disk 
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Appendix IV - Table of definitions 


Page Definition or rule name. . 


Occurs 


: Precedes 


Same_trans 

Excludes 
Excludes_node 
Node:.excludes_node 
Last + af 7 
Front 

Gains 

Releases 

Busy _ 

Qsize 

Csize 

Rank 

Rank_scan 

Eval’... .. - 

Legal 

Legal_step 
Legal_dequeue 
Head_enqueue 
In_queue — 
In_same_queue 
None_ready 
Legal_transaction_step 
Complete 
Gain_complete 
Corresponding_release 
Release_follows 
Join_complete 
Leave_follows 
Transaction order rule 
Transitivity rule 

PX from gain rule 

PX from PX rule 


111: 
112: 
112: 
112: 
113: 
113: 
114: 
115: 
116: 
117: 
118: 
119: 
119: 
120: 
121: 
121: 
121: 
122: 


Event before PX rule 
Event after PX rule 

GRE clause 

GRE_def 

GRE from empty rule 
GRE from expression rule 
GX from GRE rule 

Event before GX rule 
Event after GX rule 

Event from FIFO rule 
EVT and EVF meaning 
EVF rule 

EVT rule 

EVT from conjunction rule 
EVT from disjunction rule 
EVF from conjunction rule 
EVF from disjunction rule 
Event from ready queue rule 
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